Policy-Discussion

[Ian G <iang AT cacert.org>]

Hi Laura,

On 26/03/2010 00:00, Elwing wrote:
> > >
> >
> > P.S. for those that do not understand the impact of 30 year: if in 10
> > year the encryption mechanism that was used to protect the root key was
> > broken, we'd have to revoke the key, *unless* we can prove no copies
> > exist outside the control of the board. So if we use 10 key holders, and
> > after 10 year one or two do not respond, these copies are out there, and
> > as such the root cannot be trusted anymore (the encryption *might* be
> > broken, and we are *not sure* it's not!). A CA is all about trust and
> > reliability, right? Even if everyone would respond and hand over their
> > key, we still can't be *sure* a rogue copy does not exists.
> > The only way to be a bit more sure it's not copied, is by storing the
> > key on a physical device that cannot easily be copied (for instance an
> > encrypted and PIN protected smartcard), and have full life-cycle control
> > over physical and logical access to that device (for instance in a vault
> > with access logging, in a uniquely numbered tamper evident sealbag).
> > This is non-existing at the moment, hence the complexity of the problem :-)
>
> I just wanted to respond to this part - is there a lockbox facility at the Data center 
> where the root is hosted?  Could it possibly used to store such a token?  There's a 
> list of "authorized users" that can request the contents of that box, they 
> have the pin to unlock that token. You'd effectively need two people: the Data Center 
> manager/operations staff for physical access, and the person with the PIN for logical 
> access. The PIN could be changed if necessary.


I don't know if there is one, but they could always be asked.

Another possibility is to put the lockbox itself into the rack.  It has 
some space, and this would provide a further role to the access 
engineers who control access to the machines.

The criteria say that only CAcert people should have access, so having 
our own little lockbox in the rack makes more sense than involving 
externals.  Also, it makes audit a lot easier because it is all in scope 
that way, we don't have this "oh, that's their problem, you have to go 
speak to them ..." deadlock.

Also, note Dan's post, that we want to deal with legal impounding.  The 
easy way to think of this is to think about the RIAA.  Some competitor 
convinces them that we are running a file-sharing service (by whatever 
means) and they get an order to seize & impound from the Judge.  12 
months later, we might get it all back, and we might be able to 
embarrass them before the Judge, but by then it's too late.

(I've seen this attack done on a business that was doing experimental 
crypto work that happened to look like music sharing.)


> Another method I've seen (and it's been audited against the Federal bridge, 
> but not any of the WebTrust/etc audits) is that the root key is stored on the 
> RootCA hard drives.  The drives are RAIDed - 2 need to be brought together to 
> bring up the CA.  However, this only works when you've got an off-line root.


The method that was suggested in 2008 was to store passwords on one USB 
stick and the root on the other.  This was reasonable, technically, to me.

The real question left over was who holds each stick, and how long can 
we rely on that for?  This in the end proved a killer question.



iang

PS: I'm fascinated by the use of RAID in a governance protocol, but I 
guess we're not auditing them so I'll stay quiet ;-)

PPS: each USB stick was actually two, duplicated, to cover for hardware 
failures.