== Overview == Use banks/notaries to store passwords and keys separately. Source;[[http://wiki.cacert.org/Roots/EscrowAndRecovery/PassSigningServer|Faramir]] == Principles == 1.- We encrypt the certificates with something like AES (GnuPG allows to encrypt files with symmetric algorithms), or to an OpenPGP key created for escrow purposes. We store the encrypted certificates (and the private key, if we use OpenPGP) into an USB flashdrive. But we _don't_ put the passphrase (either the passphrase for symmetric encryption or the passphrase that unlocks the secret OpenPGP private key). And we put this flashdrive inside a sealed envelope labeled "Envelope 1A" (plus dates and other details to identify it). 2.- We store the passphase, in plain text, inside another USB flashdrive, and we put it inside another sealed envelope labeled "Envelope 1B" (plus dates and other details to identify it). All of this is done in the presence of 2 or more people of CAcert. For obvious reasons, the person that enters the passphrase must not keep the first envelope. 3.- Now lets imagine banks offer a service for storing the envelope inside a safe box, which require 2 signatures from authenticated current members of the board. We put envelope 1A in a bank, and envelope 1B in another bank. Advantages: a. Files and passphrase are not together. Even if a bank employee tries to access the certificates, the employee can't do anything because he lacks the other envelope. a. There is no need to a proper handover, people leaving the board lose the capability to do anything to the envelopes. Disadvantages: a. First we need to find 2 banks or notaries that provide that storage service. a. Cost. I don't have any idea about how much would a bank charge for that service. a. Time. How much time do we need to authenticate board members to the bank (specially after a handover)? a. Can we check the backups from time to time, without having more costs? a. Single point of failure. Even bank vaults can be accessed (some years ago, a group of thieves stole the content of a vault, accessing it using an underground tunnel), or where may be disasters (some years ago, I saw a new about a man losing his money, because the vault was invaded by termites, which literally ate the money). This can be mitigated by creating envelopes 2A and 2B (not interchangeable). == 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 ||<(> Board control as strong as banks' authentication system || || z.2 ||<(> subroot handled separately || || z.3 ||<(> root is definitely offline|| || z.4 ||<(> no critical sysadmin control so board is fully in control || || z.5 ||<(> reliable - recent experience (Ernie and AU bank) to sign onto a bank was slow. Reliable once control gained though. Teus also found difficulties in this approach || || z.6 ||<(> cost - big question - probably not $0 || || z.7 ||<(> recovery as quick as bank processes occur. Foreign banks/notary release could be slow || || z.8 ||<(> risk of disclosure is very low with banks and hopefully notaries || [[Roots/EscrowAndRecovery#SecurityPolicy|Security Policy Requirements]] || [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html#SP9.2.1|SP9.2.1]] || Board has full control and sole control on root key || || [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html#9.2.2|SP9.2.2]]-a || single purpose media used || || [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html#9.2.2|SP9.2.2]]-b || encryption + password with physical separation used in liue of dual encryption || || [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html#9.2.2|SP9.2.2]]-c || yes - passwords on separate media || || [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html#9.2.2|SP9.2.2]]-d || dual control regularly enforced by banks || || [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html#9.2.2|SP9.2.2]]-e || board control is absolute || || [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html#9.2.2|SP9.2.2]]-f || subroots not addressed || || [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html#9.2.3|SP9.2.3]] || arbitrator recover is assumed|| [[Roots/EscrowAndRecovery#DRC|DRC Requirements]] || '''C.3.c''' ||<(> The root certificate private key is stored secure from electronic and physical compromise. || ||||<(> Confidentidality yes - integrity limited by number of copies.|| || '''C.3.d''' ||<(> The root certificate private key is stored by the CA and not by any outside party. || ||||<(> Bank storage used. Confidentiality is assured. Integrity and availability are less certain.|| || '''C.3.e''' ||<(> The root certificate private key pass-phrase (i.e. password) is not stored electronically or physically. || ||||<(> stored in conformance with SP || || '''C.3.f''' ||<(> The root certificate private key pass-phrase (or parts thereof) is known only to CA personnel || ||||<(> Access by CAcert personnel only. Memory of the person who enters the passphrase could be a risk. || || '''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). || ||||<(> The bank storage of each item is a single point of failure. Dual USB devices mitigate electronic failure. || || '''C.3.h''' ||<(> Provision is made to prevent loss of use of the root certificate resulting from the loss of one key person.|| ||||<(> There are not key persons. || || '''C.3.i''' ||<(> Use of the root certificate private key requires cooperative action by at least two CA personnel. || ||||<(> Banks will ensure control || === 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 || || Z || || || || || || || || SP || || || || || || || || DRC || || || || || || || Comments: * I'm not a fan of notaries and banks: * Teus tried it. * Philipp [[https://lists.cacert.org/wws/arc/cacert-root/2010-01/msg00030.html|says]] they aren't for this purpose * Ernie took 6+ months to be identified to a foreign bank. No reason the processes for secure deposits would be different. * High cost * Limited redundancy * Low speed of recovery ---- . CategoryAudit . CategoryNewRootsTaskForce