pkcs11 — archive

[Michael StJohns]

On 4/10/2013 2:11 PM, Burns, Robert wrote: Michael, Based on this proposal, it appears that now every token that wants to work with public keys will be required to have DER encoding/decoding functions for all public keys. No. Did you miss the "If support for this attribute is implemented...." comment. The spec does two tangible things - it assigns a code point for CKA_PUBLIC_KEY_INFO and defines an encoding for that data. It doesn't require any token to support it. I think that at some point this gets added to one or more PKCS11 profiles as part of their mandatory to support attributes though. In the (somewhat distant) past, specific care was given to support tokens which only needed to work with the objects themselves by ensuring that the standard did not force tokens to implement DER/BER encoding rules (many reasons for this). Is there a way in which we could support having this field default to "empty" so that tokens are not forced to DER encode their public keys if they don't want to? That way, tokens can support the field, or choose not to. See above. If you ask for a CKA_PUBLIC_KEY_INFO on a key that doesn't have that info, then you return an error code of a missing attribute. But thanks for your comment - It reminded me that I need to add text for C_CreateObject for private keys and support for CKA_PUBLIC_KEY_INFO as part of the template. Thanks, Bob