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

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.