Re: ECDSA key parsing in crypto drivers

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

Adding Herbert Xu and David S. Miller as recipient.

On 8/31/26 11:09 AM, Paul Louvel wrote:
> 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