Roots/EscrowAndRecovery/EnvelopeBankNotaryEscrow

Overview

Use banks/notaries to store passwords and keys separately.

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:

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.
There is no need to a proper handover, people leaving the board lose the capability to do anything to the envelopes.

Disadvantages:

First we need to find 2 banks or notaries that provide that storage service.
Cost. I don't have any idea about how much would a bank charge for that service.
Time. How much time do we need to authenticate board members to the bank (specially after a handover)?
Can we check the backups from time to time, without having more costs?
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:

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

Security Policy Requirements

SP9.2.1	Board has full control and sole control on root key
SP9.2.2-a	single purpose media used
SP9.2.2-b	encryption + password with physical separation used in liue of dual encryption
SP9.2.2-c	yes - passwords on separate media
SP9.2.2-d	dual control regularly enforced by banks
SP9.2.2-e	board control is absolute
SP9.2.2-f	subroots not addressed
SP9.2.3	arbitrator recover is assumed

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.

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