OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[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


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]