RE: [pkcs11] Re: Action item #13

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
Sent: Freitag, 17. September 2021 22:13
To: pkcs11@lists.oasis-open.org
Cc: tony.cox@cryptsoft.com; Robert Relyea <rrelyea@redhat.com>; Daniel Minder <Daniel.Minder@utimaco.com>
Subject: [pkcs11] Re: Action item #13 (WARNING!!! S/MIME with incorrect signature)

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

Information Security Corp

708-445-1704 (o) | 708-822-2926 (m)

schulze-hewett@infoseccorp.com

pkcs11 message