On 01/28/2010 09:20 AM, Kai Chan wrote: > I apologize for the confusion. I was looking at certutil and how they were > handling key generation ( > http://mxr.mozilla.org/security/source/security/nss/cmd/certutil/certutil.c#2636). > It assumes you either know the key by nickname (keysource) or it generates a > new key. It initially seemed like keys have nicknames, but it looks for a > certificate: > CERT_FindCertByNicknameOrEmailAddr(certHandle, keysource) > if (!keycert) { > keycert = PK11_FindCertFromNickname(keysource, NULL); > ... > } else { > privkey = > CERTUTIL_GeneratePrivateKey(keytype, slot, keysize, > publicExponent, > certutil.options[opt_NoiseFile].arg, > &pubkey, > certutil.options[opt_PQGFile].arg, > &pwdata); > ... >
Ah, This code is part of generating a new certificate. The first part is if you are doing certificate renewal. You supply the certificate you are renewing > The functions for accessing keys are looking them up by certificate > nickname. How do I get to a key in a third-party module that has never > interacted with NSS? The functions above will work all tokens. > I'm having trouble finding any functions that take a > CK_OBJECT_HANDLE and return a SECKEYPublicKey or SECKEYPrivateKey. I got > lost looking for it myself and should have been more clear. > So my question is, where did you get a CK_OBJECT_HANDLE to begin with? In general, the object handle a third party token returns for the same object can vary. It's not allowed to vary between C_Initialize/C_Finalize calls (well unless the token is removable), but it can vary between different runs. It is even possible that the NSS softoken will return different values for the same object at different times (though this is rare). Finally, if you save an object handle in some sort of persistent way and then do a C_Initialize() and try to use that object handle, many (maybe even most) tokens will not recognize that object handle. That is because it hasn't given it to you yet. So the upshot is any object handle has not been returned by either a generate or a lookup is not valid. NSS 'tries' to hide the CK_OBJECT_HANDLE most of the time, and provide you and actual SECKEYPrivateKey, SECKEYPublicKey, PK11SymKey, CERTCertificate, CERTSignedCrl, or PK11GenericObject (the latter lets you deal with non-standard PKCS #11 objects). SECKEYPrivateKey, SECKEYPublicKey and CERTCertificate, unforutnately were not defined as opaque objects. This means that you can access their 'private' members from your program. As such, we haven't written accessor functions for those members. Upshot: You probably don't want to use CK_OBJECT_HANDLE as your way of referencing your private key, it will only work on very specific tokens. Now, if you know you are using those tokens, you can get to the private key as follows: List all the keys in the token (PK11_ListPrivKeysInSlot()). Walk down the list of keys returned looking for the key that matches the CK_OBJECT_HANDLE. Once you have the key, you may want to store the CKA_ID so you can use PK11_FindKeyByID(). NOTE: both CKA_ID and CK_OBJECT_HANDLE are token specific, and therefore need to the token where the key is stored saved as well. The different is CKA_ID is a persistant across different program instances and CK_OBJECT_HANDLE is not. bob > Thanks, > Kai > > On Wed, Jan 27, 2010 at 8:40 PM, Robert Relyea <rrel...@redhat.com> wrote: > > >> On 01/27/2010 03:38 PM, Kai Chan wrote: >> >>> Hi, >>> >>> From what I gather, keys are generated with matching certificates. >>> >> If you mean 'when keys are generated, they have matching certs', then >> the answer is no. Keys are generated bare. When the cert is imported, it >> 'latches' on to the keys that it's related with. There's a special >> dance, where NSS uses a CKA_ID for the key that is generated from some >> unique component of the public key. This is the only time NSS expects >> the CKA_ID to be some specific value. >> >> If you mean 'in a provisioned token (which keys and certs)', the keys >> and certs are matched with their CKA_ID's in triplets (private key, >> public key, cert). I'm going to try to answer the remaining assuming >> this is what you main >> >>> If I reference existing keys in a external PKCS #11 module, I would >>> have to use their CK_OBJECT_HANDLE. If wanted to be able to reference >>> these external keys by nicknames, what would I use to generate >>> certificates? >>> >> Again the use of 'generate' is confusing me. In normal usage it means >> 'create a new cert from scratch'. That is given a Key, create a cert >> from that key. This operation involves building a certificate request >> from the private key, signing it and passing it off to a CA which >> generates the cert an sends it back to you. Then importing the result >> back into the token. It's a fairly involved process and I'm assuming >> this is not what you meant. >> >> If you mean given a token with some keys and a cert, how do I get a >> handle to the private key based on the nickname? Then the answer is, >> look up the cert by nickname (PK11_FindCertsFromNickname()). Make sure >> it's the cert you want (it's possible for multiple certs to map to the >> same nickname), Once you have the cert you call >> PK11_FindPrivateKeyFromCert(). >> >> >> >>> Since they don't exist, I wouldn't be able to do >>> PK11_FindKeyByKeyID(). Are you supposed to use >>> PK11_MakeIDFromPubKey() and PK11_GetLowLevelKeyIDForPrivateKey()? >>> >> I'm not sure what you are trying to get here. PK11_MakeIDFromPubKey() >> and PK11_GetLowKeyIDForPrivateKey() already take a key, so why are you >> looking for the ID at this point? You could use >> PK11_GetLowLevelKeyIDForCert() followed by PK11_FindKeyByKeyID(), but >> then why wouldn't you just call PK11_FindPrivateKeyFromCert() to begin >> with. >> >> You need to be clear what exactly you have, what exactly is in your >> token, and what it is you are trying to find. >> >> bob >> >>> Thanks, >>> Kai >>> >> >> -- >> dev-tech-crypto mailing list >> dev-tech-crypto@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-tech-crypto >> >> >
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
