Jamie Nicolson wrote: >I am planning to support two means of extraction: wrapping with a key, >and exporting an EncryptedPrivateKeyInfo (which is an elaborate form of wrapping).
maybe its too late for input on this, but... I think that EPKI and wrapping should be sufficient as long as there is no requirement that a key is tied to a certificate. That is too clunky for some usages of keys. When I was trying to do this very thing having to have a certificate created in order to export a key was not an accurate assumption in our system. Assume that keys are generated and then must be exported. Maybe we do certificates for our public keys, but that shouldn't necessarily be a requirement of the PKI api we are using, right? And I can buy the requirement that private keys are in EPKI format. That's what PCKS#8 is for anyway right? So to summarize my response to your request for comments, "YES". Thanks, Jasen Halmes Jamie Nicolson wrote: > I'm implementing JCA compliance for JSS, and I'm trying to figure out > all the ways I need to export private keys. Why not just support exactly > those ways that the JCA supports? Because we would have to change NSS in > order to implement some of them. For example, exporting raw private keys > is currently not supported by NSS. > > I am planning to support two means of extraction: wrapping with a key, > and exporting an EncryptedPrivateKeyInfo (which is an elaborate form of > wrapping). > > Does anyone need something else? Anyone need to export a plain > PrivateKeyInfo? Can anyone make a case for exporting raw private key > data? Keep in mind that most PKCS #11 tokens don't allow raw key data > export for security reasons, and that's not going to change. The NSS > token only allows it if it was explicitly allowed when the key was created.
