[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pkcs11] CKA_PUBLIC_KEY_INFO
I'm of the view that the C_CreateObject should require (going forward) that sufficient information to return the public key is provided when creating a private key object. This is a change. It will break applications which currently do not provide this information - again implementers can elect to provide workarounds of various forms - but there isn't a universal solution as Mike has already pointed out - if you haven't been provided the public exponent in C_CreateObject for an RSA private key and you are not using F4 then you are stuck - being unable to return it. See the statement - "The only attributes from Table 3 for which a Cryptoki implementation is required to be able to return values are CKA_MODULUS and CKA_PRIVATE_EXPONENT." - and we also have this for PKCS#1 keypair generation - "Note: Implementations strictly compliant with version 2.11 or prior versions may generate an error if this attribute is omitted from the template." Separately we need to finally fix the issue with the linkage between related objects simply not being well defined - we do have conventions (thanks to a very popular profile of usage from BobR et al) but there is nothing explicit in the specification that can be relied on. That means we may need to have a real unique identifier - either a new attribute or a meaningfully defined CKA_ID to actually be required to be unique for a given token. Right now it is clearly defined as being pretty much arbitrary as to how it is handled. Once you can identify a given object we then need a way to handle the linkage between them in both directions - that means a few more attributes to do this. I also think if we had the linkage between the objects then perhaps some of the use cases we are discussing might actually be solved. Tim.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]