RE: [pkcs11] Action item #13

[Daniel Minder <Daniel.Minder@utimaco.com>]

All,

I did a little bit of RFC analysis and comparison for ECDSA and Edwards keys. If you want to skip the details start with the 2nd to last paragraph.


For ECDSA, the private key is just an integer, and the public key CKA_EC_POINT is defined as "DER-encoding of ANSI X9.62 ECPoint value Q". Looking at X9.62, there is only the public key mentioned in Annex E "ASN.1 Syntax for ECDSA". Private key d is just an integer. So, it seems the PKCS#11 representation of private and public EC keys is based on X9.62.

For Edwards, RFC 8032 says that "public keys have exactly b bits" and the "private key is a b-bit string" but also "The private key is 32 octets (256 bits, corresponding to b) of cryptographically secure random data." There is no ASN.1 module given here.

Let's look how private and public keys are used:

When using an ECDSA public key in an X.509 certificate RFC 5480 defines the SubjectPublicKeyInfo and its member subjectPublicKey, which is a BIT STRING. The ECPoint OCTET STRING is transformed into a BIT STRING as defined in that RFC but also in ANSI X9.62. Finally, the BIT STRING contains the curve point directly in compressed or uncompressed format.

RFC 8410 repeats the definition of SubjectPublicKeyInfo and says: "Both [RFC7748] and [RFC8032] define the public key value as being a byte string." Thus, the BIT STRING directly contains the b bits of the public key and no transformation is needed.

For ECDSA private keys RFC 5915 defines an ECPrivateKey SEQUENCE, that contains the privateKey as OCTET STRING converted from the integer (which is explicit mentioned). Finally, the privateKey in OneAsymmetricKey of RFC 5958 wraps this ECPrivateKey in an OCTET STRING.

Now, for Edwards keys, RFC 8410 defines that the privateKey of OneAsymmetricKey shall contain a CurvePrivateKey, which is an OCTET STRING that "hold[s] the byte sequence" of the private key. The introduction of CurvePrivateKey is probably due to the fact that all other private keys also have an "inner type" depending on the key algorithm, such as ECPrivateKey for ECDSA, RSAPrivateKey for RSA or just INTEGER for DSA.


So, comparing the encodings of Edwards and ECDSA keys based on the various RFCs it seems that both private and public Edwards keys do not require an additional ASN.1 encoding when using their values directly. Actually, it would have been best to just define them as their immediate value given as byte array of ceil(b/8) bytes.

However, since we've already introduced the DER encoding we might stay with an OCTET STRING of both private and public key values. Then, a public key needs to be transformed into a BIT STRING as for ECDSA keys although this is not in line with any RFC. At least the private key is already in CurvePrivateKey format...

Regards,
Daniel

________________________________

Utimaco IS GmbH
Germanusstr. 4, D.52080 Aachen, Germany, Tel: +49-241-1696-0, www.utimaco.com
Seat: Aachen â Registergericht Aachen HRB 18922
VAT ID No.: DE 815 496 496
Managementboard: Stefan Auerbach (Chairman) CEO, Malte Pollmann CSO, Martin Stamm CFO

This communication is confidential. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. Please inform us immediately and destroy the email.