Re: Defining custom token objects: CKO_DATA or derive from CKO_VENDOR_DEFINED class?
On 2010-01-08 13:06 PST, Klaus Heinrich Kiwi wrote: Given what you just said, openCryptoki seems to be correctly returning CKR_TEMPLATE_INCOMPLETE when NSS is trying to C_CreateObject() with vendor-defined object classes. No. CKR_TEMPLATE_INCOMPLETE means that some attribute REQUIRED by the token/module was not supplied. It is distinct from CKR_TEMPLATE_INCONSISTENT and from CKR_ATTRIBUTE_TYPE_INVALID. CKR_TEMPLATE_INCONSISTENT means that all the attribute types are valid, but the values specify a combination that cannot be supported by the token. See PKCS#11 v2.20 page 64. (I'm citing 2.20 here out of habit, but I think it does not differ significantly from 2.11 on these points.) I just realized we're doing another thing that could be considered 'marginal' to the spec. The traces shows that NSS always asks for an RSA key with 0x010001 as public exponent. Our test token (OpenSSL based) has problems with anything other than 0x03, so despite specified in the template, we override this value to 0x03, and return the key pair as nothing happened (with 3 as publ. exp.). Is this a problem in terms of spec? Yes. You should return CKR_TEMPLATE_INCONSISTENT for this. Page 64 says A set of attribute values is inconsistent if not all of its members can be satisfied simultaneously /by the token/, although each value individually is valid in Cryptoki. See page 196. The value 0x010001 is specified as the default if the template does not specify a value for CKA_PUBLIC_EXPONENT. An implementation may be a different /default/ value, especially if it cannot support the value 0x010001, but that doesn't allow it to ignore the value specified in the template. The page also says: CKA_PUBLIC_EXPONENT will be copied from the template if supplied. CKR_TEMPLATE_INCONSISTENT shall be returned if the implementation cannot use the supplied exponent value. What about NSS? I think you're asking if NSS will have problems because the requested public exponent was ignored. In this case, I don't believe it is the cause of your problem. Whether that could EVER be a problem is a broader question that I'm not prepared to answer here. It appears to be querying for publ. exponent values even though it was specified in the template, but can this be influencing in the issue I'm having? I don't think that's the cause of your failure. See below. --- output --- # certutil -S -d test-nssdb/ -h mytoken -n TestCert5 -s cn=popcorn.ltc.austin.ibm.com,o=ibm,ou=ibm,c=us -t u,u,u -c dummyCAcert3 Generating key. This may take a few moments... certutil: could not find certificate named dummyCAcert3: security library: bad database. Bad database simply means record not found in database. It's not an indication that that database is corrupt, but merely that it didn't contain what you told NSS to expect it to contain. This also applies even in cases where no database is involved. If you tell NSS to search another token, and it doesn't find what it's looking for, it can report this error. In this case, you told NSS to find a cert named dummyCAcert3 and use the private key for that cert to sign the new cert you're requesting. It didn't find any cert by that name, and so was unable to honor your request. certutil: unable to create cert (security library: bad database.) end Traces shows that the C_GenerateKeyPair() succeeds, but then, after querying for the modulus and setting CKA_ID for both keys, NSS apparently tries to sign something using the (newly generated) private key handle (isn't that odd?) No. NSS is generating a PKCS#10 CSR, which is a self-signed document. After NSS generates the CSR, it then goes to issue a cert based on the info in the CSR. It fails at that step because it cannot find the issuer (CA) cert you told it to use, namely dummyCAcert3. Everything returns CKR_OK but NSS goes to CloseAllSessions and C_Finalize(), returning the above message. Explained above. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Defining custom token objects: CKO_DATA or derive from CKO_VENDOR_DEFINED class?
On 01/08/2010 10:08 AM, Klaus Heinrich Kiwi wrote: Hi, I've been debugging openCryptoki for compatibility problems with Mozilla NSS, and I noted that, when creating a certificate using certutil, Mozilla NSS tries to create a token object with CKA_CLASS=0xce534353, which is the 'vendor defined' class CKO_NSS_TRUST, defined as ((CKO_VENDOR_DEFINED|NSSCK_VENDOR_NSS) + 3). This breaks openCryptoki as it is not expecting to be able to create custom objects (via C_CreateObject) using a 'vendor defined' class type (but only CKO_DATA objects apparently). What you you mean by 'breaks'. Does openCryptoki return an error (definitely not broken behaviour), or does it do something unfriendly like crash (definitely broken behaviour). Checking the spec (particularly v2.11 which ock implements), it reads: Object classes CKO_VENDOR_DEFINED and above are permanently reserved for token vendors. So at first impression it seems to me that ock's interpretation was right - Vendor defined classes should be reserved for token vendors (i.e., the ones implementing the interface), and not for any client library to create it's own. Comments? Anyone knows how other PKCS#11 libraries address this? (particularly the ones which are compatible with Mozilla NSS) NSS needs attributes that are not defined by PKCS #11. It uses these attributes in it's own PKCS #11 modules. You are free to return CKR_INVALID_ATTRIBUTE when you see these attributes (which is what you should return). NSS should be able to deal with that. If not let me know. (Most likely NSS will choose another token that supports this object and store it there). NOTE: In general, if NSS asks you to do something that you do not support, it is not necessarily an error for you to return that the request was not valid. NSS will switch to a different token in those cases. NSS depends on the PKCS #11 module properly signalling that it can't do something (or the session has been destroyed, or any number of other error conditions) rather than trying to build complex matrices of possible fail conditions and always asking for operations it expects to work. Thanks, -Klaus -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Defining custom token objects: CKO_DATA or derive from CKO_VENDOR_DEFINED class?
On 01/08/2010 05:10 PM, Robert Relyea wrote: NSS needs attributes that are not defined by PKCS #11. It uses these attributes in it's own PKCS #11 modules. You are free to return CKR_INVALID_ATTRIBUTE when you see these attributes (which is what you should return). NSS should be able to deal with that. If not let me know. (Most likely NSS will choose another token that supports this object and store it there). NOTE: In general, if NSS asks you to do something that you do not support, it is not necessarily an error for you to return that the request was not valid. NSS will switch to a different token in those cases. NSS depends on the PKCS #11 module properly signalling that it can't do something (or the session has been destroyed, or any number of other error conditions) rather than trying to build complex matrices of possible fail conditions and always asking for operations it expects to work. Given what you just said, openCryptoki seems to be correctly returning CKR_TEMPLATE_INCOMPLETE when NSS is trying to C_CreateObject() with vendor-defined object classes. In our traces we see NSS querying and trying to create objects using CKO_NSS all the time so I was expecting this to be the reason behind some of our compatibility problems, but looking more closely now it seems it doesn't relate. The issue I'm seeing, in case anyone is interested: I can create self-signed certificates (certutil -S ... -x) but fail at creating a cert signed by another CA cert in my database (certutil -S ... -c 'nickname'). --- output --- [r...@popcorn klausk]# certutil -S -d test-nssdb/ -h mytoken -n TestCert5 -s cn=popcorn.ltc.austin.ibm.com,o=ibm,ou=ibm,c=us -t u,u,u -c dummyCAcert3 Enter Password or Pin for mytoken: ..snip.. Finished. Press enter to continue: Generating key. This may take a few moments... certutil: could not find certificate named dummyCAcert3: security library: bad database. certutil: unable to create cert (security library: bad database.) end Traces shows that the C_GenerateKeyPair() succeeds, but then, after querying for the modulus and setting CKA_ID for both keys, NSS apparently tries to sign something using the (newly generated) private key handle (isn't that odd?) Everything returns CKR_OK but NSS goes to CloseAllSessions and C_Finalize(), returning the above message. Any clues? Thanks, -Klaus -- Klaus Heinrich Kiwi | kla...@br.ibm.com | http://blog.klauskiwi.com Open Source Security blog : http://www.ratliff.net/blog IBM Linux Technology Center : http://www.ibm.com/linux/ltc -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Defining custom token objects: CKO_DATA or derive from CKO_VENDOR_DEFINED class?
On 01/08/2010 06:19 PM, Klaus Heinrich Kiwi wrote: On 01/08/2010 05:10 PM, Robert Relyea wrote: NSS needs attributes that are not defined by PKCS #11. It uses these attributes in it's own PKCS #11 modules. You are free to return CKR_INVALID_ATTRIBUTE when you see these attributes (which is what you should return). NSS should be able to deal with that. If not let me know. (Most likely NSS will choose another token that supports this object and store it there). NOTE: In general, if NSS asks you to do something that you do not support, it is not necessarily an error for you to return that the request was not valid. NSS will switch to a different token in those cases. NSS depends on the PKCS #11 module properly signalling that it can't do something (or the session has been destroyed, or any number of other error conditions) rather than trying to build complex matrices of possible fail conditions and always asking for operations it expects to work. Given what you just said, openCryptoki seems to be correctly returning CKR_TEMPLATE_INCOMPLETE when NSS is trying to C_CreateObject() with vendor-defined object classes. In our traces we see NSS querying and trying to create objects using CKO_NSS all the time so I was expecting this to be the reason behind some of our compatibility problems, but looking more closely now it seems it doesn't relate. The issue I'm seeing, in case anyone is interested: I can create self-signed certificates (certutil -S ... -x) but fail at creating a cert signed by another CA cert in my database (certutil -S ... -c 'nickname'). I just realized we're doing another thing that could be considered 'marginal' to the spec. The traces shows that NSS always asks for an RSA key with 0x010001 as public exponent. Our test token (OpenSSL based) has problems with anything other than 0x03, so despite specified in the template, we override this value to 0x03, and return the key pair as nothing happened (with 3 as publ. exp.). Is this a problem in terms of spec? What about NSS? It appears to be querying for publ. exponent values even though it was specified in the template, but can this be influencing in the issue I'm having? Thanks, -Klaus --- output --- [r...@popcorn klausk]# certutil -S -d test-nssdb/ -h mytoken -n TestCert5 -s cn=popcorn.ltc.austin.ibm.com,o=ibm,ou=ibm,c=us -t u,u,u -c dummyCAcert3 Enter Password or Pin for mytoken: ..snip.. Finished. Press enter to continue: Generating key. This may take a few moments... certutil: could not find certificate named dummyCAcert3: security library: bad database. certutil: unable to create cert (security library: bad database.) end Traces shows that the C_GenerateKeyPair() succeeds, but then, after querying for the modulus and setting CKA_ID for both keys, NSS apparently tries to sign something using the (newly generated) private key handle (isn't that odd?) Everything returns CKR_OK but NSS goes to CloseAllSessions and C_Finalize(), returning the above message. Any clues? Thanks, -Klaus -- Klaus Heinrich Kiwi | kla...@br.ibm.com | http://blog.klauskiwi.com Open Source Security blog : http://www.ratliff.net/blog IBM Linux Technology Center : http://www.ibm.com/linux/ltc -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
