Overview
This method seeks to offer a simple and straight-forward method of root key protection that is low cost, has low administrative overhead and addresses all the settled criteria.
Principles
- An existing offline root server exists (or will exist) on a server with no network connectivity in our existing secure colo facilities.
- One or more backup offline root server will be configured, and stored:
- within the same rack; or
- in a different rack at the same facility; or
- in a second secure colocation facility
- The decision of where to store the second server is a balance between cost, available resources and the risk of a catastrophic disaster event at a single location.
- The process of backing up the offline root server occurs each time the root is (re-)issued.
- No need for new policies or procedures, as we have existing policies, such as the Security Manual, which are already in place for the root key server.
- No new actors are introduced into the root key's security considerations, as it is controlled in the same manner as the primary copy of the offline root.
Procedures
The root key is transported to each backup offline root server on (re-)issue by two members of the critical systems administrators, in accordance with the Security Policy.
Additionally, sub-roots and OCSP certificate keys could also be backed up in the same fashion.
Costs
- One or more additional servers, either new, or re-purposed. ($0-$2000)
- Costs of actually backing up the key should be close to zero, as it should not add any expenses that didn't already exist from establishing the key on the first offline root server.
Key Storage
Key is stored in the same manner as the primary offline root.
Risks
If the backup offline root server(s) is/are stored in a single location and a disaster event could cause the physical destruction of all copies of the root key. This risk should be mitigated as part of a wider disaster recovery plan (through the use of multiple physical locations).
Assessment against Requirements
Author Assessment
- This is the assessment by the proposal author:
z.1
The board is in control in the same way it controls all critical infrastructure
z.2
This proposal does not otherwise affect the subsequent use of the root
z.3
The root key is offline in the same manner as the primary root key copy
z.4
Board has de jure control of critical infrastructure, and can exercise this as needed.
z.5
Method's reliability scales with requirements, and can scale with appropriate disaster recovery plan, and would be considered part of overall DR plan
z.6
Method incurs little to no additional costs
z.7
As this method proposes a mirror of the offline root system, recovery is on a "hot swap" basis
z.8
As this method introduces no new actors with access to any part of the root key, it has zero effect on the confidentiality of the root key
Complies. All actors already bound by SP.
SP9.2.2-a
Substantially complies, if removable media is used in the backup servers. I submit the word "removable" should be struck from this clause though unless it's also envisaged that the main offline root server will use removable media also.
SP9.2.2-b
The root keys is protected in the same method as the original copy.
SP9.2.2-c
The root keys is protected in the same method as the original copy.
SP9.2.2-d
The root keys is protected in the same method as the original copy.
SP9.2.2-e
Authorised by the board by direction to the critical systems team.
SP9.2.2-f
Authorised by the board by direction to the critical systems team.
All actors are background checked and are subject to the CCA and SP.
C.3.c
The root certificate private key is stored secure from electronic and physical compromise.
Existing access control procedures protect the physical security, whereas the system being offline with no external connectivity protects it from electronic compromise.
C.3.d
The root certificate private key is stored by the CA and not by any outside party.
Root is stored under the control of CAcert, Inc., not through the use of RAs or other non-background checked actors.
C.3.e
The root certificate private key pass-phrase (i.e. password) is not stored electronically or physically.
Complies.
C.3.f
The root certificate private key pass-phrase (or parts thereof) is known only to CA personnel
Complies.
C.3.g
Provision is made to prevent loss of the root certificate through a single-point of failure of electronic equipment (including physical destruction of such equipment).
Addressed through wider Disaster Recovery Plan.
C.3.h
Provision is made to prevent loss of use of the root certificate resulting from the loss of one key person.
Method relies on no single person.
C.3.i
Use of the root certificate private key requires cooperative action by at least two CA personnel.
Existing dual control regime provides.
Community Member Assessment
- You, the community member are encourages to assess this procedures also. Please fill out the table below with a 1-10 rating with 1 being strongly meets criteria and 10 being fails criteria. Comments: (as you wish)
Z1
Z2
Z3
Z4
Z5
Z6
Z7
Z8
SP9.2.1
SP9.2.2-a
SP9.2.2-b
SP9.2.2-c
SP9.2.2-d
SP9.2.2-e
SP9.2.2-f
SP9.2.3
C.3.c
C.3.d
C.3.e
C.3.f
C.3.g
C.3.h
C.3.i
Z
SP
DRC
Community Member Assessment by XXXXX