[Pki-devel] lightweight sub-CAs; updated design

Simo Sorce ssorce at redhat.com
Fri Oct 17 17:34:37 UTC 2014


On Fri, 17 Oct 2014 10:04:32 -0700
Christina Fu <cfu at redhat.com> wrote:

> sorry I missed a few folks in my reply ...
> 
> On 10/17/2014 10:01 AM, Christina Fu wrote:
> > Hi Fraser,
> >
> > This response is for the "Key generation and storage" part of the
> > design.
> >
> > First of all, Dogtag does provide symkey retrieval via a JNI
> > package which provides interface to NSS called "symkey".  There had
> > been talks of merging symkey functionalities into JSS (which is
> > also a JNI package that provides interface to NSS) in the future.
> >
> > In fact, for years, Dogtag has been doing what's similar to what 
> > Petr^2 Spacek described with DNSSEC, the wrapping/unwrapping of
> > keys on both NSS softtoken as well as supported HSMs for
> > distribution without ever disclosing any private keys in memory.
> > This is the most basic requirement for Common Criteria for RHCS.
> > This is just to assure you that whatever you need, it's most likely 
> > already there and more.
> >
> > BTW, I'm not familiar with "SoftHSM".  The name itself sounds like
> > an oxymoron, but we don't have to get into that ;-).
> >
> > As far as HSMs go, once keys are generated, you are not going to be 
> > able to export any private keys out of it unless they are temporary 
> > and non-sensitive keys, which should not be the case for CA signing
> > keys. In practice, since HSMs are expensive, people use net HSM so
> > servers can share the same hardware unit as long as they are within
> > the same secured network, which means that you don't have to try to
> > distribute the certs and keys, as long as you have the right 
> > permission/privileges and enough info to access such network shared
> > HSM. In cases when sharing of an HSM is not possible, HSM vendors
> > provide assistance to "copy" keys from one HSM to another.  When
> > our customers run into that, we ask our customers to contact their
> > vendor(s). In some situations, process can be taken to generate
> > keys on soft token in a secure and isolated location and manually
> > import to individual HSMs.
> > What you do not want to do, is to put your CA signing keys anywhere 
> > other than an isolated backup facility or in the token itself, no 
> > matter how many times you wrap it.  Ciphers get cracked every few 
> > years, and when your CA private keys are compromised, the
> > consequences are insurmountable.
> > You might ask, why then KRA keeps the wrapped user private keys on
> > the ldap server for archival/recovery?  The answer is very simple.
> > Those are user keys.  It would be bad if they are compromised, but
> > not as bad or widespread.  Also, those user private keys are
> > wrapped with individual session keys (every key is different),
> > unlike what DNSSEC is doing with one single "master key", if I read
> > it correctly (I apologize I did not have time to look into DNSSEC
> > at all). Anyway, Dogtag has a long history of serving facilities
> > that require high security, so that's why it is what it is today.

This is all fine but this feature we are describing is used to wrap
subCAs, should a subCA key be compromised it is relatively easy to
replace it. People that do not want to expose those keys will simply
not enable any synchronization mechanism and level keys permanently in
the HSM.

Simo.


-- 
Simo Sorce * Red Hat, Inc * New York




More information about the Pki-devel mailing list