RE: [pkcs11] Inconsistent CKA_EC

Daniel,

Thank you for quoting the spec on DER which makes it crystal clear. I have reached out to the HSM vendor about the issue.

Thanks again,

Jonathan

From: Daniel Minder <Daniel.Minder@utimaco.com>
Sent: Thursday, June 4, 2020 9:28 AM
To: Jonathan Schulze-Hewett <schulze-hewett@infoseccorp.com>; pkcs11@lists.oasis-open.org
Subject: RE: [pkcs11] Inconsistent CKA_EC_POINT encoding

Jonathan,

I don’t think there’s a problem here.

PKCS #11 Current Mechanism spec says: “DER-encoding of ANSI X9.62 ECPoint value Q” for CKA_EC_POINT (section 2.3.3)

ITU-T X.690 (08/2015) says in section 10.1 (subsection of the “Distinguished encoding rules”): “The definite form of length encoding shall be used, encoded in the minimum number of octets. [Contrast with 8.1.3.2 b).]”

Note the word “minimum”.

Your examples would only be possible with BER. In fact, see note 2 in section 8.1.3.5 of X.690: “In the long form, it is a sender's option whether to use more length octets than the minimum necessary.” But PKCS #11 requires DER.

Or did I miss something?

Best,

Daniel

Dr. Daniel Minder

Product Manager

Utimaco IS GmbH, Germanusstr. 4, DE-52080 Aachen

phone: +49 241 1696 - 519

From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> On Behalf Of Jonathan Schulze-Hewett
Sent: Mittwoch, 3. Juni 2020 15:46
To: pkcs11@lists.oasis-open.org
Subject: [pkcs11] Inconsistent CKA_EC_POINT encoding (WARNING!!! S/MIME with incorrect signature)

All,

I just bumped into this today. My understanding is that CKA_EC_POINT needs to be ASN.1 DER-encoded as an OCTET STRING (0x04). For public key values with length less than 128 bytes I believe there is only one way to encode it (0x04|1-byte length|public key). However, for public key values with 128 or more bytes there are multiple ways to encode it

0x04|1-byte length bytes|1-byte length|public key

0x04|1-byte length bytes|2-byte length|public key

0x04|1-byte length bytes|3-byte length|public key

…

Where the X-byte length field is zero padded.

For example:

0481850401a8f3fad872e92fa34e3cb0c1ec631fa8a6b2797c727aadea6b41bd1c28972c6d12fac8fc9e6d0d544a7d062cd9d427c36102a49cbc6d960edcd87d8730e1b8d33c005e2bb06e2b7cddad51b2c9a599fca8025f884ccd722c19701cf00cc1e8708d2a9a23b6056252e5982ac71593b2e548754fbf19180f2898189c3a238f583b261f7f

048200850401a8f3fad872e92fa34e3cb0c1ec631fa8a6b2797c727aadea6b41bd1c28972c6d12fac8fc9e6d0d544a7d062cd9d427c36102a49cbc6d960edcd87d8730e1b8d33c005e2bb06e2b7cddad51b2c9a599fca8025f884ccd722c19701cf00cc1e8708d2a9a23b6056252e5982ac71593b2e548754fbf19180f2898189c3a238f583b261f7f

This makes it difficult to find objects with a particular public key in them without trying multiple types of encoding.

Is it correct that both encodings are acceptable? If so, can we clarify the spec so that the minimal length DER-encoded value is used?

Thanks,

Jonathan

Jonathan Schulze-Hewett

Director of Development

Information Security Corp

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

schulze-hewett@infoseccorp.com

Utimaco IS GmbH
Germanusstr. 4, D.52080 Aachen, Germany, Tel: +49-241-1696-0, www.utimaco.com
Seat: Aachen – Registergericht Aachen HRB 18922
VAT ID No.: DE 815 496 496
Managementboard: Stefan Auerbach (Chairman) CEO, Malte Pollmann CSO, Martin Stamm CFO

This communication is confidential. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. Please inform us immediately and destroy the email.

pkcs11 message