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