Policy-Discussion

[Ian G <iang AT cacert.org>]

Some comments,  good to see there is some energy here!


On 23/03/2010 12:34, Daniel Black wrote:
> At the board meeting of 20100321[1] the board held an inquisition of Multi-
> member escrow.[2]


It is good that we have a number of proposals.  I see them all as 
whiteboarding proposals, and hopefully they will feed off each other.  I 
doubt any will survive as is, because we are looking at one of the most 
difficult tasks, and collecting the people to apply the brain power to 
this task is also a non-trivial aspect here.  It might take many mails & 
months to get this done;  there is no deadline.


> 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)


Not that I know of, no thought has been given, and see next:

> * Community control may not meet audit requirement on CAcert control (Mario)


Hmm...  I read that debate and thought it interesting.  I wouldn't 
expect an Auditor to rule definitively against community control. 
Currently all critical / security stuff is under two levers of control, 
being Security Policy and Board.  But, the former is by far the more 
serious because it is backed up Arbitration.  In contrast, Board control 
is simply about appointment, delisting and reporting.  It's relatively mild.

So, one would think any "key holder/guardian" would probably fall 
immediately under SP, which rules on this area... which I think is 
fierce enough.

(prepare for 60 more ABCs ;)

Mario's point might still be good, but on the other hand, it might apply 
to a whole lot more things as well, such as a requirement that all 
critical roles also be Association Members.


> * Encryption is not enough (Lambert)


Concur.

> 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.


Pointing to Lambert's comment that encryption is not enough, this is a 
more subtle point, in that encryption rarely breaks, it is more that the 
persons & copies migrate into a statistically unsustainable space.

Also, see Laura's comments about collusion;  I would see the structural 
and people arrangement as the key to this, and the crypto would be the 
supporting tool, not the other way around.


> -------
> 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.


I don't think being on the board is particularly relevant.  People get 
voted onto board for popularity;  not security pedigree.

Auditors look to see that the board has control;  not the key itself. 
Most Auditors would probably raise eyebrows at the average board having 
sole control without assistance and protection, because they are often 
old fogies who likely need secretaries to send an email.  We're a bit 
different, but the general principle remains.  People who hold critical 
assets or play a role are under SP, not "part of the board" and should 
be competent to that task.


> -------
> 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).


Yes, I like this part.  If we can drop the requirement for CRLs (???) 
then this makes things much easier.  It reduces the problem space from 
"critical revocations" to "denial of cert service" which is easy.

> 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?


Which, is multiplied by the number of copies and the time.  This is my 
significant concern with the proposal, in that 50 + 10 looks like too 
many, too quickly weak over time.

E.g., once we find that there is a breach, how do we identify which of 
the 50 + 10 were at fault?  If it were 3 + 5, we'd have a chance at 
investigation.


> 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.


Yes, under SP.

> 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.


This assumption I would not be happy with.  "Not totally trusted" means 
we can expect a breach.  Which means all the load is now on the other 
group.  Any one of those can be compromised, leading to total compromise.

(I might be reading this wrong, you might mean, neither side is "totally 
trusted".)


> 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.

ok, let's assume these guys are selected well.

> 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



I've somewhat run out of time here, so I'll send this off HALF finished 
... coz the other half might not happen for days.  Sorry about that.




iang

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature