[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [pkcs11] Re: Action item #13
Hi Daniel, Yes, pPublicData as part of the CK_ECDH1_DERIVE_PARAMS. SoftHSM is a bit of a maze, but as far as I can tell, it handles the private keys as a string of bytes (like they do for ECDSA). It appears that they interpreted v3.0 to be “same as ECDSA”. Sincerely, Jonathan From: Daniel Minder <Daniel.Minder@utimaco.com> Hi Jonathan, you refer to pPublicData as part of CK_ECDH1_DERIVE_PARAMS, right? Therefore, we also need to look at section 6.3.17 “Elliptic curve Diffie-Hellman key derivation”. It seems we’ve just added CKK_EC_MONTGOMERY to the table of allowed key types there, but did not make any other changes. In both sections 6.3.16 and 6.3.17 the references to ANSI X9.62 and X9.63 make sense for this key type since ANSI does not know Montgomery curves. We should have added RFC 7748 there, too. And with this addition to pPublicData we can also clarify how the public key need to be formatted for ECDH. Therefore, in my opinion we cannot deduce anything for the formatting of an Montgomery public key from the current definition of pPublicData. But you certainly pointed out another missing item in the spec. Did you check how SoftHSM handles the private keys? Regards, Daniel From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> On Behalf Of Jonathan Schulze-Hewett All, I agree with Daniel that the private key CKA_VALUE definitions were fine as they were and should be reverted to something like the v3.0 wording. b-bit private key value in little endian order as defined in RFC 8032 Private key value in little endian order as defined in RFC 7748 Could both be “Private key bytes in little endian order as defined in RFC XXXX”? RFC 8410 gives the BIT STRING encoding of the public key as it’s defined in the RFCs. This indicates that there is no other encoding. The public key is just its bytes, it’s not encoded. Their example: BIT STRING : 19 BF 44 09 69 84 CD FE 85 41 BA C1 67 DC 3B 96 : C8 50 86 AA 30 B6 B6 CB 0C 5C 38 AD 70 31 66 E1 v3.1 Section 6.3.16 (v3.0’s 2.3.16) strongly prefers pPublicData to be just the raw bytes, but implementations MAY support the DER-encoded ECPoint from ANSI X9.62. Since ANSI X9.62 doesn’t apply to these types of keys v3.0 requires that the public key be input as just the raw bytes. The v3.0 definition of “DER-encoding of the b-bit public key value in little endian order as defined in RFC 8032” and “DER-encoding of the public key value in little endian order as defined in RFC 7748” does not clearly define the encoding. The type is not specified so one could encode it as an OCTET STRING, a BIT STRING, a CHARACTER STRING, etc. Rooting around in SoftHSM2’s code which claims to support Montgomery and Edwards curves they’ll accept a point as raw (as required) or as an OCTET STRING when creating the objects and in the C_DeriveKey parameters for ECDH. They also always return the public key as a DER-encoded OCTET STRING. So there’s at least one implementation that has taken the definition in v3.0 to mean OCTET STRING. There’s likely one somewhere that decided on BIT STRING because that’s how it is in certificates. Since it wasn’t well defined previously we’re likely to break something. To be fair, I think we should just break everything and say the public key is the “Public key bytes in little endian order as defined in RFC XXXX”. Sincerely, Jonathan Jonathan Schulze-Hewett Director of Development 708-445-1704 (o) | 708-822-2926 (m) schulze-hewett@infoseccorp.com
|
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]