Thanks a lot for your valuable help Jasen. But I still have some questions about your workarounds:
1/ Unfortunately this is not a solution for us because one of the main goal of using JSS and NSS in Java and C environment is to have a common keystore and tools to manage it (certutil and pk12util). 2/ Same as 1/. This is not a solution for us. We need to use PrivateKey for encryption methods. 3/ How can I get a EncryptedPrivateKeyInfo (or a PrivateKeyInfo) from a PrivateKey ? PrivateKeyInfo needs a octet_string (from a byte array) representation of the private key ... so if PrivateKey.getEncoded() return null, I have no chance to get this octect_string ... Did I miss something ? Thanks again from a lost (in JSS) guy. Pierre Jasen Halmes <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > I was trying to do this exact thing, if you look at the JSS source code > you'll see they don't implement this method. The explanation I got was > that it was not secure to expose a private key in plaintext. > > There are a couple of workarounds: > > 1) use a java.security.PrivateKey which requires changing your key > generation code. When you do this you can call getEncoded() and get a > byte array, however this key will not work with other mozilla functions, > I'm not sure which off the top of my head. I think my problems had to do > with trying to verify a Signature with the PrivateKey or something like > that. > > 2) use the JSS KeyWrapper and a symmetric key to get an encrypted byte > array of the PrivateKey, this adds the need to handle symmetric key > generation. I actually tried using an algorithm that will produce the > same symmetric key based on a passphrase. So then I just need to keep > this passphrase secure. This was the solution I used, BUT the bytes are > not usable by other encryption methods like for verification or whatever > so I have to convert back to a PrivateKey to do anything. I am just using > this method to store the keys. > > 3) start with the PrivateKey and get an EncryptedPrivateKeyInfo which is a > pkcs#8 format private key. Meaning that saving the > EncryptedPrivateKeyInfo to a file is how you make pkcs#8 keys. This is > how they should be stored normally I think, but I'm not positive of the > difference between this and step 2). Other than the fact that step 2) > isn't an ASN type and an EncryptedPrivateKeyInfo is. > > I hope that helps and that I didn't pass on any misinformation... > Jasen
