[Rats] Re: I-D Action: draft-ietf-rats-ear-04.txt

[Carl Wallace <[e-mail]>]

On Sat, Jun 13, 2026 at 5:37 PM Nathanael Ritz <[e-mail]> wrote:

> <snip>
> > >> Why does this matter? because libraries that load it, without
> bringing in a full DER parser.
>
> > [CW] As we get into the PQ key era, these structures can just be
> templates for byte arrays, so a DER parser would not be needed if this is
> the only residual ASN.1 definition in use. Side note, it's not the DER that
> is "unnecessary" it's the PEM wrapper that is unnecessary:-)
>
> [NR] Correct me if I am wrong, but am I understanding correctly that the
> DER format is still unavoidable in the case of PQ keys?
>

Take a look at RFC 9881 (though it is not alone in this practice):

  pk-ml-dsa-44 PUBLIC-KEY ::= {
    IDENTIFIER id-ml-dsa-44
    -- KEY no ASN.1 wrapping --
    CERT-KEY-USAGE
      { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
    PRIVATE-KEY ML-DSA-44-PrivateKey }  -- defined in Section 6


My point was that unlike RSA keys, there is no ASN.1 conveyed via the
subjectPublicKey field in SubjectPublicKeyInfo. There is still the DER in
the SubjectPublicKeyInfo, but with the algorithm field having a fixed value
per key type and the length being known, you could just read the leading
bytes as a template (without having a DER parser). Thomas is right that you
can't escape DER in all scenarios but where just talking about
SubjectPublicKeyInfo you may be able to.