Edwards key encoding history

All,

In the final 3.0 standard the Edwards and Montgomery public keys are defined as Byte array with meaning “DER-encoding of the b-bit public key value” and the private keys as Big integer with meaning “b-bit private key value” (for Montgomery “b-bit” is missing). This is basically the same definitions are for previous ECDSA keys, which was the intention of Darren when writing the proposal.

Jakub started a discussion about this definition last year. You can find the complete thread here: https://markmail.org/message/i6ybudy6un72l276

It was first discussed in this TC meeting: https://wiki.oasis-open.org/pkcs11/Meetingminutes/Minutes13052020 But there was no decision there.

In this meeting https://wiki.oasis-open.org/pkcs11/Meetingminutes/Minutes08072020 it seems that we concluded that no changes are necessary.

There was another discussion about Edwards Key Pair generation here: https://wiki.oasis-open.org/pkcs11/Meetingminutes/Minutes20012021 But IMO this is another topic not related to the encoding of pub/prv Edwards/Montgomery keys.

So, I’m wondering what now triggered the change. Maybe it was Bob’s review here? https://markmail.org/message/6tpas4f5qdyw5s6s

IMO the thread of last year mixed the encoding given in RFC8032 section 5.1.2 (“All values are coded as octet strings”) with ASN.1 encoding, where there are also octet strings. As I’ve showed in my last mail by comparison with ECDSA keys their ASN.1 encoding is based on clear ASN.1 definitions in several standards and RFC, which is not the case for Edwards/Montgomery curves.

But probably the best way is to return to the definition of PKCS#11 v3.0 and clarify our intention – or even better provide working examples that give values for CKA_VALUE and CKA_EC_POINT (and remove other attributes from the template which do not add any valuable information in all the examples across the whole specification…)

Have a nice week-end

Daniel

pkcs11 message