Skip to Content.
Sympa Menu

cacert-policy - HSM escrow - was: Re: Board inquisition of Multi-member escrow

Subject: Policy-Discussion

List archive

HSM escrow - was: Re: Board inquisition of Multi-member escrow


Chronological Thread 
  • From: Daniel Black <daniel AT cacert.org>
  • To: cacert-policy AT lists.cacert.org, Elwing <lraderman AT elwing.org>
  • Subject: HSM escrow - was: Re: Board inquisition of Multi-member escrow
  • Date: Wed, 24 Mar 2010 10:26:46 +1100
  • Authentication-results: lists.cacert.org; dkim=pass (1024-bit key) header.i= AT cacert.org; dkim-asp=none
  • Organization: CAcert

On Tuesday 23 March 2010 23:32:22 Elwing wrote:
> As I saw this on the policy list, I'm replying there only.

I'm regretting moving the new roots discussion to the 
https://lists.cacert.org/wws/review/cacert-root list.

> My first question is what mechanism is being used to store/generate the
> root keys?

The multi-member escrow proposal updates bits of this however the generation 
is :

http://wiki.cacert.org/Roots/CreationCeremony

Some scripts are used from last time:

http://svn.cacert.org/CAcert/Software/CAcertCeremonyScript/

> Is it an HSM (such as nCipher/SafeNet)?  If so, why not use
> the multi-party mechanisms built into those HSMs?

HSMs I've seen aren't guaranteed to work over the life time of the root - 30 
years.

The risk of failure was assessed as too high.

> 5 key parts are
> generated on tokens (usually referred to as the "green" tokens) and
> distributed to 5 people (board members perhaps?).

ok with board possession there is a key distribution problem. Its not 
normally 
a problem for most CAs as board members meet physically. With CAcert  you've 
got a transport problem every board change especially if using HSM.

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

really? I've never heard what reliable information on what the majority of 
CAs 
do.

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

The root handling now is a bit different because end certificates are issued 
directly off the root. There's no intent to  manage it like it currently is. 
Here's a general description.
http://www.cacert.org/help.php?id=7

Rather than create yet another proposal rather late in process (board will be 
deciding within a week), can you comment constructively on the current 
proposals?

If you feel strongly about HSM please write a proposal on the wiki and look 
in 
the archives https://lists.cacert.org/wws/arc/cacert-root for any guidance.

-- 
Daniel Black
CAcert

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




Archive powered by MHonArc 2.6.16.

Top of Page