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

On 6/12/2013 6:36 PM, Robert Relyea wrote:
On 06/12/2013 03:21 PM, Michael StJohns wrote:

Note that there are issues with wrapping certain sub types of keys (e.g. the RSA private key that doesn't store all the possible CRT data).  Should that be addressed or just mentioned as an exception? 

So I think the current PKCS #1 spec (referenced by the PKCS #8 spec) does not make the CRT values optional. That being said, you can recalculate (at some expense) all the CRT values as long as you have both exponents and the modulus. The question is who would be responsible for doing it (the module that is doing the wrap or the module that is doing the unwrap unwrap). Doing the former maintains compatibility with all existing uses (including non-PKCS #11 software). Doing the latter saves effort if both tokens don't support storing CRT values.

Which amusingly goes back to the whole problem where RSA PKCS11 private keys aren't required to keep the public exponent.  E.g. you might not actually be able to do the recalculation with the available data.

*sigh*  How about an update to this section that fakes it?  If you're missing an RSA component (other than n and d), you provide it as zero.   Would that be a security issue for an importer that didn't use this convention?  I would expect the key to fail of verification rather than be accepted.


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