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