Policy-Discussion

[Elwing <lraderman AT elwing.org>]

As I saw this on the policy list, I'm replying there only.  

My first question is what mechanism is being used to store/generate the root 
keys?  Is it an HSM (such as nCipher/SafeNet)?  If so, why not use the 
multi-party mechanisms built into those HSMs?  5 key parts are generated on 
tokens (usually referred to as the "green" tokens) and distributed to 5 
people (board members perhaps?).  At least 2 of those (up to 5 depending on 
the configuration) must be brought together to recreate the root key.  At 
that point, you have legal recourse (at least in the US) with charges of 
collusion if the key parts are brought together without permission. The HSMs 
also provide for backup tokens if necessary.
Since this is how the majority of CAs in the world handle this, I don't see 
how an auditor could fault you for doing something similar (I certainly 
wouldn't if I were auditing CACert).  

Now, I don't understand how the root key is being handled now, so this 
comment may be totally off.

Laura

On Mar 22, 2010, at 9:34 PM, Daniel Black wrote:

> At the board meeting of 20100321[1] the board held an inquisition of Multi-
> member escrow.[2]
> 
> The results are an interesting mix of comments that should of been made 
> earlier on the root list however I'll include them here:
> 
> * has thought been given to how good an idea it is to store the escrowed 
> roots 
> in NL, as opposed to somewhere where the legal entity has easier legal 
> control, like Australia (mark)
> 
> * Community control may not meet audit requirement on CAcert control (Mario)
> 
> * Encryption is not enough (Lambert)
> 
> Some positive comments:
> 
> "great plan from a novel high security escrow" (mark)
> "brilliant from protection against compromise" (mark)
> 
> Board Questions:
> 
> -------
> Q. What will we do if "secure enough" turns out to be "not secure enough"?
> 
> A.
> One aspect to "not secure enough" is not secure enough for an auditor. To 
> mitigate this risk I propose that with the implementation of Multi-member 
> escrow some board members are made to be key holders and others key 
> guardians 
> until an audit opinion on the effect of winder dissemination is made.
> 
> The other aspect is the effective protection over time is degraded. The 
> current plan provides the root key is encrypted and offline in possession 
> of a 
> number of members that the board trusts. If the encryption starts to weaken 
> the options are:
> 1. get a stronger encryption to wrap over the top. Ask our current key 
> holders 
> to apply this.
> 2. The keys are offline and stored as securely as our key holders can 
> manage. 
> If the effective protection  weakens then we've got a chance to redesign 
> our 
> key storage mechanism to mitigate the threat, call a key escrow meeting and 
> implement the new procedure.
> 3. in the case of a rapid break in an encryption we can use the dual 
> encryption variant of the proposal. Disparate encryption algorithms like 
> PGP 
> and S/MIME can be used to doublely encrypt the root key contents. A break 
> is 
> only likely to weaken one of these. In the unlikely change that it affect 
> both 
> then we actually need to trust our key holders not to exploit this and we 
> redesign a mechanism around what we know.
> 
> -------
> Q. Community control is not enough.
> 
> A. As above we can restrict control initially to the board as it provides 
> the 
> greatest chance of passing an audit. During discussions with the audit 
> options 
> for CAcert inc and CAcert community roles for keyholder and guardians will 
> be 
> discussed. The frequent changing of board members means that this solution 
> becomes a burden and risk in the long term. If it becomes an audit 
> requirement 
> we just may have to deal with it.
> 
> -------
> Q. we need quickly, because we potentially need to sign revocations
> 
> A1.
> In the case of root key changes there is no effect on revokation because 
> there 
> can't be any. We need to just advice the distributors of our key to remove 
> it.
> 
> A2.
> In the case of subroots there is an online OCSP key in control of the 
> critical 
> team to handle revokation of subroots (as per discussion on cacert-root 
> list).
> 
> A3.
> With regard to any subroot - if were generating a new subroot we the 
> subroot 
> (or a derived OCSP key) to perform the revocations.
> 
> Maybe I don't understand the question. Maybe the question doesn't make 
> sense.
> 
> -------
> Q. Ensuring our trusted group aren't bribed/coerced.  How do we do this?
> 
> The question as to who to trust is a fundamental one to the key escrow 
> problem. It is often traded of in ways for availability, cost or procedural 
> ease.
> 
> With multi member escrow the trust question is answers as follows:
> 1. The board being a responsible entity with no conflicts of interest  
> decides 
> who the key holders are. These members are trusted to follow procedures in 
> the 
> same way as our critical sysadmin team.
> 2. The key holders aren't totally trusted as they are only given an 
> encrypted 
> root key. This is mainly a two or more person control however it also 
> doubles 
> as a protection against loss or compromise.
> 3. The key guardians are selected by the board. These are the ones that 
> provide encryption keys to protect the root. Like the key guardians these 
> people are entrusted to follow procures in the case an escrow is neeeded. 
> They 
> like the key holders are entrusted to report compromises.
> 4. The dual encryption variant of this proposal means the root key is 
> encrypted twice, once with PGP and another time with S/MIME with the keys 
> from 
> two different key guardians.
> 5. The coordinator is trusted by the board to do the right thing during a 
> key 
> escrow meeting. The witnesses are trusted to validate the write thing is 
> done.
> 
> The question of reliability comes into place when trust is broken. What 
> happens when the trust of the above 4 items is broken.
> 1. Worst case - a key holder is compromised in some way and the encrypted 
> root 
> key is placed on the internet. In this case key guardians have the ability 
> to 
> decrypt a root. The most effective control here is the dual encryption 
> variant 
> which means that two key guardians are required break their trust of 
> protection to decrypt the key.
> 2. same as #1
> 3. Worst case - a key guardian is compromised and their keys are stolen and 
> placed on the internet. They key guardian does no inform the board as per 
> procedures. In this case the key holder can have one key to decrypt the 
> root. 
> This is also a good justification for the dual encryption option.
> 4. There is a break in the encryption that PGP or S/MIME provide. In this 
> case 
> the key holder has the ability, potentially with effort to decrypt the 
> root. 
> This is a good justification for dual encryption.
> 5. The coordinators actions are largely subjection the the verification by 
> the 
> witnesses present at a key. Even with the dual encryption option the 
> coordinators are in possession of both sets of keys to decrypt the root for 
> a 
> short time. In the case of the root key being put on the internet encrypted 
> then two coordinators, one getting pgp private keys and the other getting 
> x509 
> private keys would be needed to prove dual control didn't occur.
> 
> As you can see multiple layers of trust are required to be broken for any 
> key 
> compromise to occur. The careful selection of key holders, key guardians 
> and 
> coordinators by the board is required to provide strength at each layer.
> 
> -------
> 
> Lambert - can you please explain what you mean about encryption not being 
> enough. This challenges one of the SP criteria and needs to be addressed.
> 
> This proposal uses an offline root key encrypted with X509 from one key 
> guardian and PGP key from another provides sufficent protection. The root 
> keys 
> are stored in differnent locations from the guardian keys.
> 
> -------
> 
> Was there any other inquisition questions that I failed to answer?
> 
> -------
> 
> [1] 
> http://wiki.cacert.org/Brain/CAcertInc/Committee/MeetingAgendasAndMinutes/20100321
> [2] http://wiki.cacert.org/Roots/EscrowAndRecovery/MultiMemberEscrow
> 
> -- 
> Daniel Black
> CAcert

Attachment: smime.p7s
Description: S/MIME cryptographic signature