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] CKA_PUBLIC_KEY_INFO


> 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.

Indeed, although F4 is a commonly used value, it is definitely not the only value used. A solution we provide should work for all cases and not only for "common" cases.

In addition, it is very common in the smart card industry that the PKCS11#11 library will use devices with a file system that the library has no control over, i.e. a p11 module many times does not have control on what exactly can be stored on the device, so when creating a private key, even if the template will include additional attributes, it may not be possible for the module to actually store them on the device, and of course not possible to return them later on. In particular, devices (e.g. issued by governments) are being issued in mass issuance directly at the APDU level and not through a PKCS#11 library.  

 

-----Original Message-----
From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Tim Hudson
Sent: Thursday, April 18, 2013 2:57 AM
To: pkcs11@lists.oasis-open.org
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.


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 



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