OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11-comment message

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


Subject: CKM_ECDH_AES_KEY_WRAP format questions


Hi,

I am looking to implement CKM_ECDH_AES_KEY_WRAP and have few questions.
I know the spec is somewhat loose on what to output, but I'd rather
have a preferred format for the wrapped key.

Current Mechanisms v2.40 in "2.3.12 ECDH AES KEY WRAP" says the
following:
 - Wraps the target key with the temporary AES key using
CKM_AES_KEY_WRAP_PAD (RFC5649)
 - Concatenates public key material of the transport key and output the
concatenated blob
 - The recommended format for an asymmetric target key being wrapped is
as a PKCS8 PrivateKeyInfo

Now the question is what format the "public key material" is supposed
to be?

The DER-encoded, or raw octets of ANSI X9.64 ECPoint?

(The existing things are slightly inconsistent: CKA_EC_POINT is
DER-encoded, but e.g. CK_ECDH1_DERIVE_PARAMS parsers MUST accept the
RAW bytes, and MAY accept the DER-encoded version.)

...

Current Mechanisms v3.0 wd5 says in 2.3.21 (the equivalent chapter),
the following:
 - Wraps the target key with the temporary AES key using
CKM_AES_KEY_WRAP_KWP ([AES KEYWRAP] section 6.3).
 - Concatenates public key material of the transport key and output the
concatenated blob. The first part is the public key material of the
transport key and the second part is the wrapped target key.
 - The recommended format for an asymmetric target key being wrapped is
as a PKCS8 PrivateKeyInfo
 - Splits the input into two parts. The first part is the public key
material of the transport key and the second part is the wrapped target
key. The length of the first part is equal to the length of the public
key material of the unwrapping EC key.

Now the above is slightly cryptic. But it actually holds true
regardless if the DER-encoded or RAW format is used.

This also raises another question. Why the mechanism was changed from
CKM_AES_KEY_WRAP_PAD to CKM_AES_KEY_WRAP_KWP?

To speculate: v3.0 defined CKM_AES_KEY_WRAP_PAD as doing PKCS#7 padding
and then regular AES_KEY_WRAP. v2.40 sort of implies that too, the
wording in CKM_AES_KEY_WRAP_PAD definition is vague. But then in
context of CKM_ECDH_AES_KEY_WRAP it said RFC5649 so I guess v2.40 is
self-contradicting there. So I guess the change was intentional, and
expect also v2.40 to have really used the RFC5649 mode which is
equivalent of the CKM_AES_KEY_WRAP_KWP?

But the main question is, whether the the public key material portion
should be DER-encoded or the raw octet string value?

Thanks,
Timo


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