This page is part of the New Roots Task Force collection.
1. Procedures
- technical organisation of roots:
Roots/Structure describes the hierarchy and relationship between the roots
Roots/Contents describes the internal fields in each Roots.
- ceremony for creation of root (s)
Roots/CreationCeremony is open as a place to develop this need
Roots/TechScript is where the geeky arcania can be collected
- storage securely on signing server
- escrow root securely for disaster recovery
Roots/EscrowAndRecovery is open for jotting notes...
- finally, when all is good, start the rollout procedure
Roots/RolloutProcedure is open for jotting notes...
of which an important part is Roots/TestNewRootCerts
The works-in-progress procedures and guidelines above are included by reference and authorised by SP/SM. If not, fix the SM.
2. Policy
There are three major documents:
The DRAFT Security Policy is managed by policy group.
The wip Security Manual is the major practices manual containing the detail, authorised by SP. Team leaders are responsible for it.
The CPS is managed by policy group. It defers most issues of Roots to SP.
(not policies but) Risk Assessment Work underpins and supports policies and procedures.
3. Motions & Decisions
The following decisions are additional to the policies (which means they generally do not change the policies, more clarify the practical issues). They are primarily made by the Board, which has responsibility for the Roots under SP.
RESOLVED, that the existing root may not be used to sign any new sub-roots, and that the board receive reports from affected teams with a view to the issuing of a new offline root with multiple sub-roots.
On security measurements on the issue of MD5 use in signature algorithm: ...
stop signing certificates with the Class 3 CAcert Root cert with serial nr 01;
to generate a new Class 3 CAcert root key using the SHA-1 signing algorithm and start signing (intermediate) class 3 certificates with this certificate.
Motion to install Root Key Task Force CAcert Sub-Committee: task to have CAcert Root Key and 2 sub keys for assured members and for members certificate signing generated and installed by end of November 2008.
If auditor requires or advises a new Root Key for CAcert to be issued, this will take place as soon as appropriate.
m20080901.1 notes included "reissue CAcert Root Key"
have arrangement for critical system access and password to root keys at third party with disclosure instructions such that two signatures of board are required to disclose this information by the third party.
TOP 20070917 This decision had no motion:
We agree that we have to put in procedures that guarantee the security of the root keys. These procedures are more strict than the previously applied procedures, and obviously did not apply to the old root keys. Therefore, once the new procedures are in place, we will create new root keys and deprecate use of the old keys.
Note the above is summarised and the full motions may include more important parts.