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] Groups - Proposal for Secure Key Import using an RSA key uploaded

Hi  Tim.


Thanks for the comment also in the call .


The main intention for the new mechanism is for the import of an asymmetric keys.  The motivation is associated with Padding Oracle attacks.  Specifically, for symmetric key import, the use of RSA OAEP mitigates that attack risk, however due to length limits , RSA OAEP it cannot be used to import a private RSA key . Therefore, the new compound mechanism proposal comes up .


I prefer not limiting the use of the new mechanism to asymmetric keys and hoping to allow any key to be imported .  So, given the wrapping of the key may be done by one implementation and the unwrapping by a different implementation,  Mike and I added this recommendation, to provide guidance and interoperability for the formats. 


While I agree it’s  unusual , it still seems to be valid for an implementation to be useful.  Having said that  , the options that I see moving forward are :


1.       Leave the recommendation /guidance as is

2.       Provide a different format recommendation for symmetric keys

3.       Eliminate the format recommendation from the spec for symmetric keys  and leave it to the implementation decision

4.       Eliminate format recommendations from the spec (regardless of symmetric or asymmetric) and leave it to the implementation decision

5.       Limit the new mechanism strictly for wrap and unwrap of asymmetric keys   


Any other options that I missed ?






From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Tim Hudson
Sent: Wednesday, May 29, 2013 11:40 PM
To: pkcs11@lists.oasis-open.org
Subject: Re: [pkcs11] Groups - Proposal for Secure Key Import using an RSA key uploaded


These are the two sections I find somewhat strange within the proposal - raised on the call.


The recommended format for an asymmetric target key being wrapped is as a PKCS8 PrivateKeyInfoThe recommended format for a symmetric target key being wrapped is also as a PKCS8 PrivateKeyInfo, where the PrivateKey OCTET STRING is the secret target key's data. 


The use of Attributes in the PrivateKeyInfo structure  is OPTIONAL. 


The OBJECT IDENTIFIER arc { oasis pkcs11 attributes } is reserved to identify PKCS11 attributes encoded as PKCS8 Attribute objects.  The last component of such OID shall be the same as the value assigned to the corresponding CKA_ enumeraton.  I.e. the OBJECT IDENTIFIER for CKA_ENCRYPT is { oasis pkc11 attributes CKA_ENCRYPT (260) }.  It is recommended that only BOOLEAN attributes be included in the Attributes field of PrivateKeyInfo.

The information contained in this electronic mail transmission 
may be privileged and confidential, and therefore, protected 
from disclosure. If you have received this communication in 
error, please notify us immediately by replying to this 
message and deleting it from your computer without copying 
or disclosing it.

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