RE: [pkcs11] Edwards ECC keys in PKCS #11 3.0 again

Jakub:

The parameters should most certainly be the ASN.1 object identifier just as we do for ECDSA and ECDH parameters. âEdwards EC public keys only support the use of the curveName selection to specify a curve name as defined in [RFC 8032] and the use of the oID selection to specify a curve through an EdDSA algorithm as defined in [RFC 8410]. Note that keys defined by RFC 8032 and RFC 8410 are incompatible.â To me this says to take the curve name in RFC 8032 and go find the OID for it over in RF 8410. So take the curve name Ed25519Â from 8032 and then go find itâs OID in 8410 which is 1.3.101.112.

As for the public key in CKA_EC_POINT, since the subjectPublicKey encoding in RFC8410 section 4 is a BIT STRING I would use that as thatâs the only DER encoding specified in either RFC 8032 or RFC 8410. Itâs also uncommon for PKCS#11 to require that something coming from a certificate have its encoding changed for input to the API. However, I canât find anything in the PKCS#11 specification that actually says this so I could be completely wrong here. Sorry I canât be more helpful.

Sincerely,

Jonathan

Jonathan Schulze-Hewett

Director of Development

Information Security Corp.

schulze-hewett@infoseccorp.com

708-445-1704

From: Michael Markowitz <markowitz@infoseccorp.com>
Sent: Wednesday, March 11, 2020 10:09 AM
To: Jakub Jelen <jjelen@redhat.com>; pkcs11@lists.oasis-open.org
Subject: Re: [pkcs11] Edwards ECC keys in PKCS #11 3.0 again

Jakub:

>In that case, lets take an example of SoftHSM (referenced in previous
>email), which creates software token using OpenSSL primitives Ed25519
>[1], which is described as PureEdDSA, Ed25519 algorithms [RFC8032] and
>keys according to draft-ietf-curdle-pkix-04 (current RFC 8410). What
>should the the value it should present in EC_PARAMS attribute?

i think the context of your question is becoming clearer 🙂 for a PKCS#11 public key object used for PureEdDSA with Ed25519, all three choices in 2.3.3 seem reasonable to me: OID, curve name, or implicitly specified in accompanying signature creation/validation context. OTOH, see next response...

>The RFC 8032 (and example template) uses curve name "edwards25519"
>(defined from RFC 7748), so this sounds like a first think to look at
>and use. Additionally, the RFC 8410 specifies algorithm OID for the
>same curves ("Ed25519" for PureEdDSA mode) as follows:
>OBJECT IDENTIFIER ::= { 1 3 101 112 }

RFC 8410 (section 3) does state "The same algorithm identifiers are used for identifying a public key, a private key, and a signature (for the two EdDSA related OIDs)." (In my mind this is somewhat perverse, but what do I know; perhaps NIST will provide clarification at some point.) In any case, check out section 2.2 in RFC 8419!

>I assume this gives modules and applications choice which of these
>encodings to use for identifying one key, while requiring them to
>handle both of the values when creating/accepting the key. Do you read
>It the same way?

if you mean encoding the CK_ATTRIBUTE, I think I'd agree, but clearly 8419 expresses a preference for the OID (in the context of CMS), so I'd go with that.

>Second question was about encoding EC_POINT. After several more
>readings of the specs and referenced RFC, I am almost sure it should be
>OCTET STRING as specified in RFC 8032, Section 5.1.2, but I would like
>to hear an opinion from somebody else that it is their reading too.

yep, 8032 sections 5.1.2/5.2.2 say encodings are octet strings and EdDSA public points are encodings... but Jon's been working on this for the past couple of weeks so perhaps he can chime in on this point (pun intended)

Jon?

-mjm

pkcs11 message