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

Reply via email to