[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [pkcs11] Edwards ECC keys in PKCS #11 3.0 again
|
Hi, Iâm not sure if this helps at all, but here is what my understanding/intention was. Our intention for the CKA_EC_PARAMS section was that you could specify the specific curve name as defined in RFC 8032; for example the PrintableString âedwards25519â or âedwards448â. Or you could specify the
OID. Either method is acceptable. Two of the main reasons for this was that RFC 8032 did not provide any OIDs, nor did it reference any other sources of OIDs. And at the time this was added to the PKCS#11 standard, there werenât any consistent sources for
OIDs. Many of the RFCs were still in draft form, and most of them all used their own OIDs. And most of the open-source software that implemented these curves supported them by name only.
For the CKA_EC_POINT attribute, you raise a good question. The PKCS#11 spec states âDER encoding ofâ.â. But neither PKCS#11 nor RFC 8032 define what that DER encoding should be. My intention here was to be
consistent with how we manages the traditional X9 style of ECC keys. For Edwards keys, RFC 8032 defines the public key as a b-bit. So right or wrong, my intent was for CKA_EC_POINT to contain the b-bit value encoded as a DER OCTET. But as you say, it is
not clear from any of the specs. From an RFC 8410 point of view (and I have not studied it in depth), I would expect the same b-bit value to be encoded as a DER BITSTRING Thanks DJ From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org]
On Behalf Of Jonathan Schulze-Hewett 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>
Jakub: 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... 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!
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.
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]