ECDSA key parsing in crypto drivers

[Paul Louvel <paul.louvel@bootlin.com>]

Hi,

I am currently working on upstreaming the ECDSA part of a Public Key
Accelerator.
I have a question regarding which ASN.1 schema should I use when decoding the
buffer passed by the .set_pub_key() and .set_priv_key() callbacks in struct
sig_alg.
The documentation only mentions that the callbacks should "know how to decode
and interpret the BER encoded public key and parameters."

The kernel software implementation of ECDSA only supports verifying signatures,
and thus only implements the .set_pub_key() callback. In this callback, the
buffer should contain an ECC key as defined by RFC5480 section 2.2 [1].

In the downstream driver I am currently upstreaming, it expects a BER encoded
ASN.1 schema of SubjectPublicKeyInfo as defined in RFC5480 section 2 [2]. The
driver defines its own .asn1 file containing the ASN.1 schema of this sequence,
and uses the kernel's ASN.1 compiler/decoder to decode the buffer.

Because the PKA can be used to sign messages, there is a .set_priv_key()
callback that expects a BER encoded ASN.1 schema as defined in RFC5915 section
3 [3]. The same remark applies to the public key: a .asn1 file is present and
defines the ASN.1 schema described by the RFC.

My question is: which ASN.1 schema should be used? Should a client of the
crypto API know in advance which format the driver expects? Also, for RSA,
there are helpers for parsing private and public keys: rsa_parse_priv_key() and
rsa_parse_pub_key(). These helpers use the kernel's ASN.1 decoder. Would it
make sense to have such helpers for ECDSA?

Thank you,

[1] RFC5480 Section 2.2 - ECC Key Format
https://tools.ietf.org/html/rfc5480#section-2.2

[2] RFC5480 Section 2 - SubjectPublicKeyInfo
https://tools.ietf.org/html/rfc5480#section-2

[3] RFC5915 Section 3 - Private Key Format
https://tools.ietf.org/html/rfc5915#section-3

-- 
Paul Louvel, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com