Re: Action item #13

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