The May/June report to the Community on Audit progress. These reports are done on an approximately two month basis, or on a milestone. Previous and Next.
1. Systems
Critical Systems remains the critical element of the audit. It is important to realise that slow progress in the Systems area is causing serious difficulties. |
a. The plan mentioned in last report, 2.b has been dropped. This was for Evaldo to come to Europe and implement the strategic intention: rebuild the systems administration team / move the critical systems from Vienna to servers available in Netherlands. It was codenamed Cachaca.
b. The responsibility for all systems issues now falls back to the Board of CAcert Inc. The strategic intention remains to rebuild the systems administration team / move the critical systems from Vienna to servers available in Netherlands.
c. Comment: In managing the CAcert systems, there must be a team with multiple people. This is not only an audit requirement for dual control / 4 eyes, it is also because there is too much work for one person to do alone. The work must be shared out. In the short term this means that there might be a loss of productivity, as these new people require handholding; but this is normal and expected. It is unavoidable if CAcert is to deliver a scaleable and professional CA service.
d. Opinion: The primary blockage is, in my opinion, the difficulty of integrating new people in to help with the tasks. This is not a technology issue nor a tactical issue; it is a people issue. I have seen many volunteers coming forth to offer help, so it is not an issue of shortages. So far there have been some indications of discussions with new systems administrators, but only one systems administrators has been added in any meaningful way, and then only on non-critical systems. CAcert needs to integrate the volunteers that it has already found.
e. We have been in this situation (with a clear goals for more sysadms and the move of the critical services) for a year or more. The question must be asked: can CAcert construct a professional team of system administrators to run the critical systems for a certificate authority?
f. I will give it to the end of the year 2008 to find out. In the next Community report, I might outline some ideas as to where we go if the answer is in the negative.
g. Addendum: points a,b updated to clear up confusion between plan Cachaca and strategic intention.
2. Policies
a. The CAcert Community Agreement has been policy for some time now. CAP forms have been used at events with the new Agreement indicated, agreed and signed by Members seeking Assurance. This is good news, as it creates the Community in a legally sustainable and defenceable way, and each Member can be protected.
b. However, important steps have not been completed. Changes to the online account system have not been done; As a Community, we require all Members to agree to the CAcert Community Agreement. This means that there should be checkboxes and "I agree" statements in the online system, at the key places such as on joining, and requesting certificates. This indicates that softare development is stalled or diverted from the top CAcert priorities.
c. As the CCA is a major change in the relationship of all, the Members also have to be notified, as is customary. A mailshot to all accounts is needed. It is a fundamental responsibility to Members to tell them of these important changes, as well as dangerous in any dispute if it is not clear what the rules are.
d. Arbitration is slowly gathering steam. Disputes have been filed and dealt with. Challenges are being worked out, the system is being tuned. If you have done some time as an Assurer, and are looking for a new challenge, perhaps you could think about doing some time in the Arbitration forum, either as a Case Manager or as an Arbitrator.
e. Work is advancing on the Security Manual. It is now a document that can be referred to. It is not yet ready for a fuller review. However, it is not a blocking task, see 1. above.
f. Still on the list of policy work is:
- The CPS which takes its Name information from Assurance.
- CCS -- configuration control specification.
- 3PV-DaL -- a 3rd party vendor agreement, for distributors of roots
These can wait until Assurance Policy goes to DRAFT, below.
3. Assurance
a. The work-in-progress Assurance Policy is now in a call on the policy group to go to DRAFT. This means it is about to become binding on the Community. You can see it in its near-DRAFT form at PolicyDrafts/AssurancePolicy. Debates on many issues were conducted o the policy group, and are now mostly concluded.
b. The Assurance Policy brings in a few new changes, most of which will be relatively easy to deal with. Primarily, the focus shifts to include checking such things as our status: the Member being assured is indeed a Member and has agreed to the CAcert Community Agreement; Likewise, the Assurer doing the check is indeed an Assurer.
c. This is also one novel change: Assurance can now be mutual and reciprocal in all cases, if both agree. To do this, the policy specifies that the non-Assurer Member conducts the mutual Assuarance while under the supervision of the Assurer. In effect, the Assurer can now teach and coach the Member in the future role of being an Assurer. For this, the Member can award 0, 1 or 2 points to the Assurer, and we should take every opportunity to let the Member's natural skepticism develop. 0 points is fine, especially for those first times when the whole experience is uncertain.
d. Another big change is the way the points for Assurers work: Experience is now separated from Assurance. As a new Assurer does more assurances, she will be given more Experience points. As she gets Assured by other members, she might also be allocated more Assurance points. These meanings are now to be separated into two different numbers stored in the system, although the effect may be similar in the end.
e. After the Assurance Policy goes into DRAFT, the Exceptions need to be addressed: TTP, Super-Assurer, etc. Also, that is the time to start the systems work to support the above changes.
f. Now that sufficient Assurers are through the CATS Assurer Challenge, it is time to turn off the ability to assure without the Challenge. If you are an assurer under the old system, you should do the Assurer Challenge before your next assurance.
4. Audit Admin
a. According to the original NLnet Timeline, we should have completed the major documentation sets by now. We are
- about 2 months behind on Security Manual work.
- about 4 months behind on the Assurance Policy.
- Assurances should have been stopped by untested Assurers by March.
- CCS, CPS, 3PV, and Exceptions Policy documents are also backed up.
Although the policy work is slow, and is behind the NLnet schedule by around 4 months, it is not a blocking task.
b. We should by now be ready to start the evaluation of the critical systems, but those systems are no closer to readiness for evaluation. This puts the next major milestone -- readiness for systems evaluation -- some 4-6 months away at a minimum.
c. Some time around the end of the year there should be an Annual General Meeting of the Association. As well, other presentations are due at that time. Audit perspective is that at the end of the year, we approach a crunch point because of the systems issues, and that should be treated as a major report.
d. The next 2-monthly report should be around August.
e. There have been two major payments made from the audit budget; 3k to Iang as audit retainer and 1k to Pat as author of Security Manual.