On 01/28/2010 03:22 PM, Kai Chan wrote: > Thank you for clarifying. I was trying to figure out the details from this > portion in the PK11 FAQ (https://developer.mozilla.org/en/PKCS11_FAQ) : > > "How is private key handled when an external PKCS #11 module is loaded? > Is it picked up from the token when securing, or does NSS expect it to be > added in its private key database to use it? > > While certificates may be read into the temporary database, private keys are > never extracted from the PKCS #11 module unless the user is trying to back > up the key. NSS represents each private key and a pointer to its PKCS #11 > slot as a CK_OBJECT_HANDLE. When NSS needs to do anything with a private > key, it calls the PCKS #11 module that holds the key." > Ah, this package is called a SECKEYPrivateKey;). SECKEYPrivateKeys is how NSS represents keys in the token. > Okay, I see from your mention of CKA_ID, you are referring to: > "In the key generation process, NSS arranges for the key to have it's > CKA_ID set to some value derived from the public key, and the public key > will be extracted using C_GetAttributes. This key will be sent to the CA." > > I guess the issue is whether the existing keys in the external module have > valid CKA_IDs. In the PKCS #11 spec ( > ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf), this > value is empty by default for a key object. I suppose in that case I'll > take a look at how NSS is generating this. > NSS sets these when keys are generated. NSS also requires that these be set to match the associated certificate. It's possible for keys to not have CKA_ID's technically, but there is no way to find such keys, and in practice they always have an id (even if it's just a small integer, like 1, 2, 3, etc.).
bob
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
