Role of this document
The real current full policy is at Organisation Assurance Policy. This page is for rethinks, discussion, etc as to changes to OAP. This wiki page is not policy.
Audit Criticisms of OAP
Some criticisms in Organisation Assurance Policy have been expressed by the last Audit, leading to a rethink and a need for a make-over of OAP. Here are the bugs expressed by Audit (from Audit/CommunityReport20081007 2.4):
- the verification of the commonName needs to be documented according to (new) policy group decision that all information is to be verified.
- how is this done?
- how does the Org know what is ok and what is not?
- the relative responsibilities need to be laid out in the OAP:
- Organisation Assurer,
- O-Admin,
- Organisation, and
- the individuals inside the organisation.
- it has been suggested that a feature of automatic certificate populating is in place. These needs to be documented and tied into the various policy statements: verification, keys security, etc.
This may or may not be at CertApi.
Software/IntegrationInterface may or may not describe this.
- the procedure for doing the OA needs to be documented, in much the same way as the the Assurer's Handbook does it for Individual Assurance.
The OrganisationAssurance/Manual may be a good starting point for that.
(Teus:) can be chapter in AssuranceHandbook2.
how are the OAs trained? The Prospective List includes some notes on this.
- (Teus:) Org Assurance is just an addenda to Individual Assurance. Similar for the Challenge part.
- there probably needs to be a document for the Org itself
its own manual as opposed to the manual for OAs.
because of the above, there should be a new subroot for Organisations within the new roots structure.
- one reason for this is that many people in the PKI community think it important to have the ability to select amongst the various major policy sectors of the CA. That is, they want to load up the subroots in their browser and turn on one while turning off another. Because they don't trust the CA in all areas.
- Whether this is a "real logical good business" reason or not, it is something that PKI/Mozilla people look at.
- CPS9.3 and other documents establish that business information is not covered under confidentiality, unless under policy.
- OAP should probably state what privacy there is for the member/organisation.
- minor point, tuck it into any review.
Specifically, the last Audit did not review OA.
Additional
these points added after Audit's close.
- What is the procedure for training?
The Prospective List includes some notes on this.
- What is the process of communication?
via Support (Triage) or?
Cleanups
Some minor points to clean up in the OAP, in any future review:
Change Registered User Agreement to CAcert Community Agreement.
- In general, OAP should be a subset of AP, and should refer up to it. Historically, existing OAP was written well before AP, so it lacks that linkage.
- Should authorise and specify location of its practices Manual (as does AP of HB and SP of SM).