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

Hi Michael,

There's already work-in-progress in IETF WGs on CBOR wrapping
and/or encoding of X.509 certificates, including:

https://datatracker.ietf.org/doc/draft-ietf-cose-x509/

https://datatracker.ietf.org/doc/draft-raza-ace-cbor-certificates/

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
PO Box 221  Grand Marais, MI 49839  906-494-2434

On Tue, Sep 17, 2019 at 1:21 PM Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> 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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> Secdispatch mailing list
> Secdispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/secdispatch
>