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

[Jakub Jelen <jjelen@redhat.com>]

Thank you all for your answers below.

The situation around the EC_PARAMS encoding got more clear to me mostly
from the below comment from Jon. My summary is that the same key can be
referenced either by name from RFC 8032 or by OID from the RFC 8410.
Applications should be able to accept both representations and prefer
the OIDs as they are now standardized.

The sentence about incompatibility of keys from the above RFCs looks to
me like placed in wrong context and it should really be written
elsewhere or clarified that it mostly means the edwards curve keys are
incompatible with montgomery ones and vice versa. 

The last point was the encoding of EC_POINT values, which still looks
like there is not a complete agreement what should be used, whether it
should come as BIT STRING or OCTET STRING. For me, the OCTET STRING
makes more sense as it is the same encoding as other elliptic curves.

I would like to avoid similar issues as there were for CKK_EC, where
some initial implementations were not using the DER encoding, but just
the bits without Tag and length.

From here, what would be the course of the next steps to communicate
this publicly? Should somebody take AI to improve wording for 3.1?
Should we update wiki, for example here before this will get out?

https://wiki.oasis-open.org/pkcs11/DocumentClarifications

(I am sorry for asking so many questions, but I am still quite a new
here so I am not sure what are the right processes to follow)

Regards,
Jakub

On Thu, 2020-03-12 at 01:18 +0000, JOHNSON Darren wrote:
> 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
> Sent: Wednesday, March 11, 2020 1:48 PM
> To: Michael Markowitz <markowitz@infoseccorp.com>; jjelen@redhat.com;
> pkcs11@lists.oasis-open.org
> Subject: 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<mailto:schulze-hewett@infoseccorp.com>
> 
> 708-445-1704
> 
> 
> 
> 
> 
> 
> 
> From: Michael Markowitz <markowitz@infoseccorp.com<mailto:
> markowitz@infoseccorp.com>>
> Sent: Wednesday, March 11, 2020 10:09 AM
> To: Jakub Jelen <jjelen@redhat.com<mailto:jjelen@redhat.com>>; 
> pkcs11@lists.oasis-open.org<mailto: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
> 
> 
> 
-- 
Jakub Jelen
Senior Software Engineer
Security Technologies
Red Hat, Inc.