== Overview == The root password management is tricky. Putting this on on the signing server and backups manages this. Source: [[https://lists.cacert.org/wws/arc/cacert-root/2010-01/msg00010.html|Hans Verbeek]] == Principles == * The signing server is located in a properly secured location, isolated from the web, and secured with disk-encryption. * The backups are double-encrypted, and cannot be decrypted by a single person, it needs dual-control. * Control to the backups has been granted by the board to the critical-server maintenance-personnel, so is indirectly in control by the board. * The location of both the critical server and of the double-encrypted backup disk is always known, both before and after the AGM/SGM. * When the critical server team rotates, a new set of backup-encryption-keys will be made, a new double-encrypted backup is made, but the original root certificate private passphrase is not changed (the location of the root certificate private passphrase is always known, both before and after AGM/SGM). * When the root certificate private passphrase _must_ be saved elsewhere also, cannot we make an extra backup-disk, and perform double or even triple encryption on that disk with "board-keys"? When those board-keys get lost, we can destruct that backup-disk, and create a new one. So i.s.o. finding a solution how to do a proper handover of the board-keys, we only have to create a new set of board-keys after an AGM/SGM, and to create a new backup, and hand that backup to the board. == Procedures == == Alternatives == == Funding == === Key Storage === === Key Escrow === == Assessment against Requirements == [[Roots/EscrowAndRecovery#Requirements for Escrow/Recovery|]] === Author Assessment === This is the assessment by the proposal author: [[Roots/EscrowAndRecovery#Implicit|Implicit requirements]] || z.1 ||<(> The board is in control of the sysadmin staff so yes || || z.2 ||<(> structure is deal with separately || || z.3 ||<(> '''not done''' root storage unaddressed || || z.4 ||<(> '''undefined'' Is the board capable of accessing the signing backups in a meaningful way? - perhaps this was the board-keys bit || || z.5 ||<(> The control over the root passphrase is simple and reliable. '''undefined''' is the control over the root private key || || z.6 ||<(> No addition capital or ongoing costs are apparent. Personnel time overhead is minimal || || z.7 ||<(> passphrase recover is speedy. '''undefined''' the root private key recovery || || z.8 ||<(> Strong controls exist on the confidentiality of the root password. '''undefined''' is root private key || [[Roots/EscrowAndRecovery#SecurityPolicy|Security Policy Requirements]] || [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html#SP9.2.1|SP9.2.1]] || ''undefined''' || || [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html#9.2.2|SP9.2.2]]-a || ''undefined''' || || [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html#9.2.2|SP9.2.2]]-b || Yes - dual encryption is current practice on signing disk and backups (I think) || || [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html#9.2.2|SP9.2.2]]-c || Password is auto-generated to arbitrary strength. Root key separation is achieved (though undefined) || || [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html#9.2.2|SP9.2.2]]-d || Dual control is taken on the signing server || || [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html#9.2.2|SP9.2.2]]-e || ''undefined'' || || [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html#9.2.2|SP9.2.2]]-f || System admin escrow exists. Board escrow does not || || [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html#9.2.3|SP9.2.3]] || could exist || [[Roots/EscrowAndRecovery#DRC|DRC Requirements]] || '''C.3.c''' ||<(> The root certificate private key is stored secure from electronic and physical compromise. || ||||<(> '''undefined''' || || '''C.3.d''' ||<(> The root certificate private key is stored by the CA and not by any outside party. || ||||<(> '''undefined''' || || '''C.3.e''' ||<(> The root certificate private key pass-phrase (i.e. password) is not stored electronically or physically. || ||||<(> It is stored physically as per SP SP9.2.2-c with strong controls there || || '''C.3.f''' ||<(> The root certificate private key pass-phrase (or parts thereof) is known only to CA personnel || ||||<(> Yes - its storage under dual control ensures this even if it isn't "known" to personnel - its accessible only by CA personnel || || '''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). || ||||<(> Stored on backup server || || '''C.3.h''' ||<(> Provision is made to prevent loss of use of the root certificate resulting from the loss of one key person.|| ||||<(> '''undefined''' || || '''C.3.i''' ||<(> Use of the root certificate private key requires cooperative action by at least two CA personnel. || ||||<(> dual control over the signing server and backups ensures this || === 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. || 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 || || || || || || || Comments: (as you wish) ==== Community Member Assessment by Daniel Black ==== || 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 || || 2 || UD || UD || 8 || 1 || 1 || 1RK || 1RK || SP UD || UD || 1RK || 1 || 1 || 1 || 3 || 1 || DRC UD || UD || 1SP || 1 || 1 || 1 || 1 || * UD - undefined * RK - root key controls will vary this assessment * SP - I'm ignoring the passphrase not written/stored requirement when in conformance with SP Comment: * If the "root certificate private passphrase _must_ be saved elsewhere" - to meet board recovery and Z4 requirement it needs to be defined more. ==== Community Member Assessment by XXXXX ==== ---- . CategoryAudit . CategoryNewRootsTaskForce