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

Michael Richardson <> Tue, 17 September 2019 17:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 414121209BA for <>; Tue, 17 Sep 2019 10:21:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oX15at52Us4X for <>; Tue, 17 Sep 2019 10:21:20 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6FAF21209B2 for <>; Tue, 17 Sep 2019 10:21:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 93E423897C for <>; Tue, 17 Sep 2019 13:19:38 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 0D678560 for <>; Tue, 17 Sep 2019 13:21:18 -0400 (EDT)
From: Michael Richardson <>
To: "secdispatch\" <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Tue, 17 Sep 2019 13:21:18 -0400
Message-ID: <6013.1568740878@localhost>
Archived-At: <>
Subject: Re: [Secdispatch] Problem statement for post-quantum multi-algorithm PKI
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Sep 2019 17:21:22 -0000

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

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 <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-