Policy-Discussion

[Daniel Black <daniel AT cacert.org>]

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