Re: [Secdispatch] Problem statement for post-quantum multi-algorithm PKI

[Michael Richardson <[e-mail]>]

The argument is about the timing.
Whether we need to panic now or not.  Some suggest "we have time"

My comment was that automobiles are being designed around ECUs today that will
be built in 2025, which will be on the road until 2040.  So, no, we don't
have the luxury of a lot of time.

I'm personally unaware of a profile of X.509 certificates that permits a
CA to sign multiple public keys with multiple algorithms.  RFC5280 says:

   Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }

I don't see a SET here, just a sequence.

We (the IETF) can't solve the problem of ECUs having multiple hardware
assists ourselves.  If I were working in that area, I'd already be looking
through all the NIST submissions from last fall and figuring out what I need
to accelerate them, and what operations are in common, and figuring out if I
can accelerate the common operations, can I win regardless of which one is picked?
Or at least, be closer to market to pick one or three variations.

Rotiling RFC5280 so that we can support multiple signature algorithms on
certificates means that we can get new CAs and related things deployed.
I'm with Stephen in asking if the DER encoding is worth keeping at this
point.

Encode ASN.1 in CBOR (CBOR encoding rules for ASN.1) if we think the ASN.1 is
worth keeping, switch to CDDL if not.  We probably need to keep the semantics.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-