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

Ira McDonald <> Mon, 16 September 2019 21:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E0FE9120116 for <>; Mon, 16 Sep 2019 14:48:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wDokU1vgwC9U for <>; Mon, 16 Sep 2019 14:48:09 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 570BB1200D5 for <>; Mon, 16 Sep 2019 14:48:09 -0700 (PDT)
Received: by with SMTP id b1so668400vsr.10 for <>; Mon, 16 Sep 2019 14:48:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QZ6MVXfNkKd/pWtMfe+nJprminxOrWf2ab53Tp0TTKQ=; b=BWYvWws9j54vCV3yGgquJEPr8YZx5W2C1PwvFFC5BhVADtSBC6XmI6hKpEkLEq60u9 d3QdvtuvhedLwh4UzTE4X1OnNXVQ0KuGw7LgL5cq/4lXMKGg3A4FHZsorRuR5NZla8ZA uW/8pyiZHs3+bcSj3JYL6SegcatgbGgTYdAYRrb9fttR3wtDHx9tvlDNG4CkDsDpukXJ RXNwjdAXyYQMB2i9XKuzFUHT24/ftxrNH6RDRKsK0eexOCqDdbpzdZ+wYOL3XDTL6ZWL +c3fwIJkZpezc8g92qYnJRTmlWrKlIXxFOi4+FPwkDtsZ2Txp3MO4WAO2iyVtqubgXE9 V67A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QZ6MVXfNkKd/pWtMfe+nJprminxOrWf2ab53Tp0TTKQ=; b=C3ZZ16ESpgXu1dNgmJURn6oHaXtUkM750Xk3TFfR6/+04lUaZTFjPIbh6QJLmOIRon LpItgq1/VcnqRVwQ0IzqvxtwF7QVv8S1jPQV36upmJa78Lvu382E8C8efLXOsAmd72U0 hYbpEXAiA8zyUYUdFxgN6m2mciVcf3iuTPxwltEycI53liMAMGkVc4Umde7MynORDVBc EGfA36+h+N86cdSU9qt4HX/2VDyt2e+XMrJ6nZ+Y5fb40+dDif6LR+H0p/ZWTkoYCJVy 9PZyjeJikgNRgtrCGvP1LnFNdRr+lUqpMYQuzKk9eGvZTT7XpcP79e44TfTZaZ3aoubZ 3mzg==
X-Gm-Message-State: APjAAAV8Mt+ku9u5w2tlZVTkAE4LoTHWHxH73MJDNhdgIoK9uWvwj0CO 6TlSnSQINlQbD7ZMIjkW9ALzKzZkFUUnW4zA128=
X-Google-Smtp-Source: APXvYqz6Q2yhvgK3qZTS6i7YwtfcYptPBNFapXVlHfeO7uP2sK+sG0+h2ZvEFxTaJ/4s06TkrtIl7WqsIvAlj+JHN8s=
X-Received: by 2002:a67:f9cf:: with SMTP id c15mr110746vsq.240.1568670488440; Mon, 16 Sep 2019 14:48:08 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Ira McDonald <>
Date: Mon, 16 Sep 2019 17:47:57 -0400
Message-ID: <>
To: Stephen Farrell <>, Ira McDonald <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="0000000000003bb56f0592b28f30"
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: Mon, 16 Sep 2019 21:48:13 -0000

Hi Stephen,

The autos *are* going to have regular OTA firmware updates
to some of their ECUs (they already do so, in many cases).

The unsolved problem is to change to a whole new family of
crypto algorithms in those updates, because there couldn't
be any crypto hardware acceleration.  Autos already have
application layer add-ons for internal vehicle network security
in many cases.  If those crypto algorithms (NOT standardized
in SAE or by regulations) have to change, then the only cure
is blanket replacement in a dealer service bay of all of the
ECUs.  Because the "son of AES" (for example) won't be
feasible because of message timing constraints in those autos
without hardware acceleration.  These are typically constrained
ECUs without the available horsepower to just use the software
versions of entirely new crypto algorithms.

I hope that was more clear.  The problem is real and urgent,
given the current digital ECU counts in autos (from 100 to 259

I don't defend this situation at all, but the auto OEMs and the
hands-off regulators have long since abandoned mechanical
control units.

- 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
PO Box 221  Grand Marais, MI 49839  906-494-2434

On Mon, Sep 16, 2019 at 4:59 PM Stephen Farrell <>

> Hiya,
> Replying to various folks at once...
> On 15/09/2019 15:29, Ira McDonald wrote:
> > Hi,
> >
> > Thanks for the link to Kenny's talk.
> >
> > Stephen - The hard problem for automotive vehicles is that, even if
> > Quantum Computing never comes to pass, algorithms and various
> > implementations go on having new weaknesses found over time.
> > But decent performance requires hardware assist, in many cases.
> > But automotive ECUs are very unlikely to start have large FPGAs
> > added soon.  Replacing 100s of expensive ECUs in fielded vehicles
> > to allow practical algorithm agility is not going to happen.  This issue
> > that Michael Richardson mentioned is at the top of the list for the
> > automotive cybersecurity community.
> I don't understand how devices that are not going to be updated
> can support algorithm agility. Perhaps you mean that you want to
> deploy those devices soon and not update for a couple of decades
> or something? If so, that sound like a bad plan to me, and one
> that'd be better to not cater to really. (RFC8240 has lots of
> discussion of that.)
> On 16/09/2019 17:05, Mike Ounsworth wrote:
> > My Goal: multi-vendor interop on PQ certificates.
> That seems to beg the question again as to why x.509 is needed
> at all as part of a PQ solution.
> > I'm coming from the
> > perspective of a CA; it can take years to distribute a root cert to
> > all the places it needs to be before you can really start using it.
> > Plus, people want to playing with these things ASAP to understand the
> > scope of infrastructure changes required. There's the time pressure.
> >
> > I think you're right that to really deploy any meaningful 20 year
> > root using, for example the small lattice schemes, we'll need to wait
> > for the NIST PQC algs to stop having so much churn.
> >
> > That said, laying the groundwork for the "hybrid" property in
> > certificates that the NIST PQC community is calling for will require
> > much debate and a few RFCs. This work is necessary and independent of
> > the choice of algorithm from the NIST PQC competition, so why should
> > we wait until 2023 to _start_ thinking about it? Why not do it in
> > parallel, be able to offer alpha test versions of PKI products before
> > the conclusion of the NIST PQC, and be ready to drop-in the NIST
> > winners the day they're ready?
> One reason to not do it in parallel is that we don't know how the
> winning algorithm parameters will look. I can easily imagine NIST
> modifying how those are encoded and/or introducing new variations,
> after basic algorithms have been picked, leading to things having
> to be re-done.
> (Sorry if the quoting is messed up below, if so, it was messed up
> in my MUA before I started is my excuse:-)
> On 16/09/2019 19:06, Daniel Van Geest wrote:
> > Can we support multiple signatures inside a certificate? I don't
> > think so.
> >
> > Why not?  Mike’s problem statement draft has two potential technical
> > solutions doing just that, each with advantages and disadvantages.
> > Or is there more of a logistical or other issue?  Knowing why you
> > think we can’t support multiple signatures inside a certificate could
> > help refine the problem statement.
> Again, that assumes that x.509 is a sensible part of a solution.
> We should first question that. (Mike's draft [1] doesn't.)
> Secondly, even if x.509 additions were useful somehow for backwards
> compatibility (which I find hard to believe TBH) then dealing with
> >1 certificate is likely far easier than messing about inside certs
> and thereby breaking all the lovely/horrible x.509 code out there.
> So Mike's section 2.1 [1] is way easier than the 2.[2|3] approaches,
> despite it being the one with no specific drafts.
> Again, all that said, I do understand why it may be attractive
> for those who produce certificates to argue for putting the PQ
> magic beans inside x.509. There are costs elsewhere implied in
> doing that, so it ought not be a starting-out assumption.
> I don't consider the question as to why a PQ x.509 is needed
> nor why now has been satisfactorily answered so far.
> Cheers,
> S.
> [1]
> _______________________________________________
> Secdispatch mailing list