OASIS PKCS 11 TC

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 vs 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   Attachment: smime.p7s Description: S/MIME cryptographic signature

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 vs 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.

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 vs 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. Attachment: smime.p7s Description: S/MIME cryptographic signature

On 6/3/20 6:46 AM, Jonathan Schulze-Hewett wrote: 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. DER already specifies mimimum encoding of the length field. Not holding to the DER specification can lead to issues (including security issues). DER means Distinguished Encoding Rules, which means only one way to encode an ASN.1 value, as opposed to BER (Basic Encoding Rules), which allows multiple ways. In BER you can extend the length value with zero padding. bob   For example: 0481850401a8f3fad872e92fa34e3cb0c1ec631fa8a6b2797c727aadea6b41bd1c28972c6d12fac8fc9e6d0d544a7d062cd9d427c36102a49cbc6d960edcd87d8730e1b8d33c005e2bb06e2b7cddad51b2c9a599fca8025f884ccd722c19701cf00cc1e8708d2a9a23b6056252e5982ac71593b2e548754fbf19180f2898189c3a238f583b261f7f vs 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