Policy-Discussion

[Daniel Black <daniel AT cacert.org>]

Thanks Ian,

On Wednesday 24 March 2010 10:51:07 Ian G wrote:
> On 23/03/2010 12:34, Daniel Black wrote:
> > * 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.

http://www.austlii.edu.au/au/legis/nsw/consol_act/aia2009307/s33.html

A committee member of an association  who ... caus[es] detriment to the 
association is guilty of an offence (Maximum penalty: 240 penalty units or 
imprisonment for 2 years, or both).  1 penalty uni t is $110 (Crimes 
(Sentencing Procedure) Act 1999 No 92 section 17)

its got bite

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

more options for key responsibility is good.

> > * Encryption is not enough (Lambert)

It was a comment in a rushed board meeting so context is definitely missing 
here. I'm hoping to get this context one day soon.

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

I think i've answered the statistically sustainable space below. Just need to 
come up with figures.
 
> 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.

Are you in favour of a key split? In both cases crypto enforces dual control 
and protects against compromise if stolen. I don't see the difference.

> > -------
> Auditors look to see that the board has control;  

can you elaborate here?

> > -------
> > Q. we need quickly, because we potentially need to sign revocations
> > 
> > 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 (???)

I can't see why we can't drop CRLs - at least for subroots if not beyond.

> then this makes things much easier.  It reduces the problem space from
> "critical revocations" to "denial of cert service" which is easy.

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

I'm tending to agree the numbers here are too high.
> 
> 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.

Is breach identification an issue? If we've got a breach our only recourse is 
to reissue. Having a smaller number means that we can use a totally new set 
of 
people.

> > 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".)
 
I hope to trust the people to do the right thing and follow procedures. I 
suspect that breaches due fire, theft (even if they didn't know what they 
stole) may occur. In these cases there a procedures as to what to do and what 
actions to take.

The dual encryption variant places the obligation on three breaches for 
compromise. Assess the likelyhood of each, the acceptable risk probability  
and we can work out the maximum number of key holders/guardians.

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

board responsibility for the root. board responsibility to choose the right 
people. Lets hope they do it right :-)

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

Its a good start. Thank you


-- 
Daniel Black
CAcert

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