The January 2009 report to the Community on Audit progress. See also: all others. Previous. Next

1. Systems

1.1 Work-thru of Critical Systems

1. The work-thru continues. At the meeting on 28th November, the following was reported by the critical team:

   1. backups -- under control

   2. passwords+keys -- half way

   3. change control -- not started

2. Into the new year, these things are on the task list.
3. Next chance to review progress is likely early February.

1.2. New Roots

1. New roots were created on 28th November.
2. These are structured as such:
   1. a single top-level root for distribution to vendors. It signs other subroots only.
   2. a subroot for all Members. This would be like the old Class 1.
   3. a subroot for all Assured Members. This would be like the old Class 3.
   4. two spare subroots.
3. The new root and subroots are awaiting some internal testing.
4. A question is whether to create a separate subroot for organisations.
   • It would be very useful to have a clear control mechanism and signalling to allow an appropriate "turn-on" of organisation certs;
   • This would also be appropriate for Members to work with, as part of their reliance obligations.
   • if not, this might present a strain on the reliance, control and governance aspects.

   • this would match the emerging Mozilla lingo and assurance views of IV, OV, AV, DV, etc.

   • As we know, Audit position is to defer the Org audit in this current cycle because of concerns.

5. My conclusion is that there should be a separate subroot for organisations.

1.3. Team Participation

1. The most important strategic aspect for the systems administration team is to grow the team.

2. I am told that 2 people are joining the critical systems team in the new year. This is good news! More are needed...
3. As a practical matter, it looks like the critical systems team will be dominated by the Dutch in the near future.
   1. this puts a lot of strain on background checking. A wip document on this process has been started, and it will be needed for the Security Manual.
4. The non-critical team is still too small to sustain its work load, but likely attention will remain on the critical team for the next 6 months.
5. The support team has a similar dilemma.

2. Policies

2.1 The CAcert Community Agreement

Important steps with the CAcert Community Agreement are still to be done. Checkboxes to Agreement, CAP forms on the main site, Members not notified. More on the wiki...

2.2 The CPS -- Rolling Again

1. The Policy group decision (p20081016) of all information in a cert needing to be verified has now been incorporated into the CPS. Implementation is still pending.

2. Because Organisation Assurance has no implementation of this, it is deferred.
3. The second "bug" in the CPS is now resolved

   1. a new policy decision (p20090105.1) states what is to happen.

   2. Some of this has been incorporated into CPS.

   3. This now needs implementation. This is a big task.
   4. Without implementation, likely any use of the new roots will be blocked for ordinary (unassured) Members.
   5. This decision is now being reworked into the CPS.
   6. When the CPS goes to DRAFT, it may replace the decision with its new more detailed description. We'll see.
4. The CPS is likely to be presented to Policy group soon.
   1. It's very big, likely it should be read section by section.
   2. In my opinion, sections 1-5 are more or less ready.
   3. Sections 6-8 need to be rejigged to refer a lot of info over to the Security Manual.
   4. Section 9 just needs more review!
5. In terms of special certificates, the CPS is likely to follow the style of the AP and OAP and refer to separate policies.
   1. Code-Signing is the one of concern.
   2. This likely effects only the new roots.
   3. So without some regime such as a separate policy document, no code-signing in new roots.

2.2 Security Manual

1. Pat (paw) passed across the first draft of the Security Manual (thanks to Pat)
   1. At this point, she has done all she can from the theoretical / best practices viewpoint.
   2. SM is now the responsibility of the Board to work
   3. Security Manual went through a work-thru by Teus and Iang.
   4. Direct information is needed to fill out the gaps.
   5. What is there is a reasonable base.
2. SM is lacking the following sections.
   1. Facility. (OOPHAGA).
   2. Disaster Recovery (Board)
   3. Systems Administration. (Sys Adm team)
   4. Software. (Software Development Team)
   5. Support. (Support Team).
   6. Background checks. (Board / Philipp D)
3. I am told these tasks are all carved up and handed out.

   1. Over to you! If you want your audit, do the tasks

2.3 Other Policy Areas

1. The Assurance Policy has now gone to full POLICY.
   1. It needs to get onto the website quickly, as the external signal to the world.

   2. This: Assurance Policy to [[|here on website]] please.

2. Any exceptions to standard Assurance are now ruled by the full policy

   1. they can only be done under suitable policy provisions, in accordance with the AP.

   2. The Exceptions: TTP, Super-Assurer, Junior, etc. Coming soon to a Policy debate near you.
   3. Especially, no more than 50 points can be issued by any process.
   4. TTP lacks a seperate policy, so probably can't be done.
   5. Super-Assurer -- same, same.
   6. Junior-Assurer -- there is no language that would say what to do here.
   7. TVerify -- again, no policy, so no go.
3. All exceptional Assurance processes are subject to Arbitration
   1. An Arbitrator can be asked to reverse or shut down anything done outside policy.

2.4 Organisation Assurance

1. OA has a lot of things that need to be fixed.

2. For reference, the list of things to fix are now located in wip Policy Changes page.

3. Some have suggested that it be included in the current Audit cycle.
   1. There is a lot of work to do, and not a lot of people available to do it.
   2. This work is on both sides of the Audit fence -- for myself and for CAcert.
   3. TANSTAAFL. The work has to be done, and OA has to meet the standards.

3. Audit Thinking

3.1 The Current Cycle

1. Audit is concentrating on getting the barriers cleared away for Assured Individual Members.
2. Recently, the CPS barrier was cleared away for non-Assured Individual Members, so it may be possible to easily include these as well.
3. This would mean: deliver an opinion that permits the subroot for Assured (Individual) Members to be used, and potentially add the (unassured) Member subroot as well.
4. Once done, the subroots would have to be carefully controlled by all participants and the code.
   1. This means that the addition of new sorts of certificates, or the weakening of the overall service in any way, will have ramifications beyond CAcert.

3.2 "An Open Audit"

1. I presented on the entire audit at LISA2008, in November.

2. The basic document is on my site at iang.org/papers

   • it is around 96 pages long (printers watch out),
   • it includes the basic html slides embedded in it
   • the formatting derives from my very old perl scripts for publishing papers, hence it is a bit odd.

   • further comments on blog1 and blog2.

3. The basic plot of the paper is to tell the whole story.
   • the good bits, and the bad bits
   • much criticism there!
   • nothing new if you have read these reports and followed progress.
4. The talk will likely improve in the future
   • Only about 50-60% of the material was presented
   • as time goes on there is more to say.

4. Admin

1. The board has appointed Philipp Dunkel to be the CAcert Member responsible for interfacing with the Audit process.
2. Payments.
   1. Phase 2 retainer is paid out, as is current expenses.

   2. Current situation is summarised at AuditBudget.

3. A task now is to prepare a plan for the operational checking parts of the Audit.
   1. this involves visiting the servers and critical systems people in the Netherlands
   2. therefore the two blocking actions (they say OK, and the SM says OK) have to be cleared, or accepted as partial.

4. The next 2-monthly report should be around March.

---

Previous. Next. all.

---

CategoryAudit