Roots/EscrowAndRecovery/ActorPassword

Overview

Principles

Procedures

the mailing list cacert-root [*]. This means all board members have to subscribe to this list.
Two acting groups are formed:
- "Actors Groups"
- Group A1: Board (CA) member, two administrators
- Group A2: Two Administrators of the signing server plus a CA member out of group 2 below.
Two other groups which will know half of the private key each. The number of members depends on redundancy demands:
- "Password Groups"
- Group P1: Administrators of groups A1 and A2
- Group P2: Board members or general CA members, preferably in vicinity of signer server and/or root ceremony location
Group A2 creates CSRs for a previously defined set of intermediate certificates on the signer server, and publishes the CSRs on the mailing list cacert-root [*]. The private key will not leave the signing server.
Meanwhile each groups P1 and P2 separately select a passphrase part. The parts may exclusively shared with members of the same group. This is the only communication that is strictly private and will not be logged.
Group A1 creates the certificates on a freshly installed netbook. Analog to [1] each member of group a has a CD with the OS chosen for operation, each tested for integrity. Randomly choose CD, install without access to any network. Create the root certificate: members of P1 and P2 enter their part of the password secretly.
The CRLs for the intermediate certificates will be signed: stored on a USB stick which must be checked by all three persons involved to be empty, except the CSRs. The signed public keys (PKCS-7 files) will be copied back to the USB stick and distributed on the mailing list cacert-root [*].
All actions will be logged, the logs will be published [*].
A sealed envelope gets the external medium with the generated root certificate and a print on paper, and is stored together later with the netbook in the safe. If a backup at an external location is required, a second envelope must be prepared.
The netbook gets physically sealed and stored together with one sealed backup in a safe (on storage medium plus one printed paper in one envelope). This safe is located at one of the CAcert.org members (institutional member).
Contract with the chief security officer ensures, that only authorized CAcert members can access the safe content after a board resolution for this access exists on list cacert-root [*].
Both groups A1 and A2 personally sign a protocol with all actions performed during the signing ceremony to hand of the board.

[*] Communication is public and secured with signature and fingerprint [1] https://wiki.cacert.org/Roots/CreationCeremony [2] https://wiki.cacert.org/Roots/Contents

Left open (but discussions in progress):

- which intermediate certificates to create - what to include into all certificates [2]

The password split means that it does not have to be changed if members in possession of one part of the password leave CAcert. If CRLs don't have to be signed with the root certificate and a suitable set of intermediate certificates has been set up, there will be no need to access the root certificate for years.

However, if the root has to be accessed, the board has to publish decision and authorization on cacert-root (current board members are always listed on website). One member of group P2 together with administrators (P1) are granted access from the chief security officer. Do work, reseal and document as during root creation.-

Assessment against Requirements

Roots/EscrowAndRecovery#Requirements for Escrow/Recovery

Alternatives

Funding

Key Storage

Key Escrow

Assessment

This is the assessment was done by Daniel - feel free to correct:

Implicit requirements

z.1	Board in control - (needs more specification around the safes)
z.2	meet - root signs subroot and CRLs
z.3	Root is offline in envelope, laptop and a spare printed copy in safe elsewhere
z.4	Recover without sysadmins - though A1 and A2 specify admins they don't need to be. Board has access by an as yet undefined method
z.5	Redundancy on people and root keys is acheived
z.6	Cost is low depending on if we have someone to volunteer exclusive use a safe
z.7	Requires meeting of board members and password groups. Can be achieved though attention to the required members is needed
z.8	Protections is dependant on safe control and password strength

Security Policy Requirements

SP9.2.1	Root generation is by board email
SP9.2.2-a	Exclusive storage on laptop and hardcopy
SP9.2.2-b	Single vs dual encryption is used - password for root two parts
SP9.2.2-c	Passwords to be shared amongst two groups. Implicitly remembered by memory refreshing between groups
SP9.2.2-d	Dual control achieved by password control
SP9.2.2-e	Board control assumed in safe procedures
SP9.2.2-f	Subroots to be with sysadmin team in operation(assumed). Copy in safe too(assumed)
SP9.2.3	Procedures known by members

This is the assessment by the proposal author:

DRC Requirements

C.3.c	The root certificate private key is stored secure from electronic and physical compromise.
in safe: ok; backups treated with same policy: ok
C.3.d	The root certificate private key is stored by the CA and not by any outside party.
ok, organization is member, chief security officer can be made member.
C.3.e	The root certificate private key pass-phrase (i.e. password) is not stored electronically or physically.
complete pass-phrase not known to anyone. Are parts allowed to be stored?
C.3.f	The root certificate private key pass-phrase (or parts thereof) is known only to CA personnel
ok
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).
ok: Paper based backup is not electronic equipment
C.3.h	Provision is made to prevent loss of use of the root certificate resulting from the loss of one key person.
ok: Pass-phrase is distributed, each part known to a group of persons. Key access is not exclusive to one person
C.3.i	Use of the root certificate private key requires cooperative action by at least two CA personnel.
ok: people from 2 groups needed for pass-phrase, and access granted only after additional authorization by board).

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.

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

DRC

Comments: (as you wish)

Community Member Assessment by Daniel Black