OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [pkcs11] RSA PKCS key generation and invalid public exponent values


I meant to type CKR_ATTRIBUTE_VALUE_INVALID in my original email, not CKR_ATTRIBUTE_TYPE_INVALID.  But that doesn’t really change anything.


Your explanation makes sense.  I hadn’t read the final example.  My mistake


And while I agree more informative error reporting would be nice, I’m not ready to take that one on yet.





From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Tim Hudson
Sent: Saturday, November 18, 2017 5:21 PM
To: pkcs11@lists.oasis-open.org
Subject: Re: [pkcs11] RSA PKCS key generation and invalid public exponent values


The use of CKR_TEMPLATE_INCONSISTENT for a valid public exponent that a token wishes to reject for token specific reasons is documented as you noted.


"A final example would be a template with an attribute that violates some token specific requirement.  Note that this final example of an inconsistent template is token-dependent—on a different token, such a template might not be inconsistent."


So if the value isn't completely illegal always then CKR_TEMPLATE_INCONSISTENT is meant to be the error return code.


This is what the lead in sentence of "CKR_TEMPLATE_INCONSISTENT shall  be  returned  if the implementation cannot use the supplied exponent value." is also stating.


The specification is being entirely consistent in that handling. Stating "conflicting values" isn't indicating what the values conflict with - either each other or with requirements of the token itself. It is explicit that a token can have its own requirements which trigger this error return code which are different from another token - so it isn't about the relationship between the various attribute values in isolation.


This wasn't unintended. 


Returning CKR_ATTRIBUTE_TYPE_INVALID would be inconsistent and confusing - as it is not the type of the attribute which is the issue - it is the value.


However the return of CKR_TEMPLATE_INCONSISTENT without indicating which attribute(s) are the issue is not all that helpful an interface. 

We discussed a number of times that improving the error return handling for at least this specific error code would be useful - so the application has some way of figuring out what the issue is - but that is a separate topic.






This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]