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

Mike Ounsworth <> Mon, 16 September 2019 16:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 925141200FE for <>; Mon, 16 Sep 2019 09:05:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SX2r0hwg4azN for <>; Mon, 16 Sep 2019 09:05:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6C3DA12004F for <>; Mon, 16 Sep 2019 09:05:24 -0700 (PDT)
IronPort-SDR: M1ajb7djimb1CNp0I4OODpB2ukuv/J05b6RV7POWo97r+xqP7bpMPvzGqkMRYJGAZ1g52Wiqs8 QFmzgXdjjBXw==
X-IronPort-AV: E=Sophos;i="5.64,513,1559538000"; d="scan'208";a="57095386"
Received: from (HELO ([]) by with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 16 Sep 2019 11:05:23 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 16 Sep 2019 11:05:23 -0500
Received: from ([fe80::8084:293e:7f03:4ab2]) by ([fe80::8084:293e:7f03:4ab2%12]) with mapi id 15.00.1497.000; Mon, 16 Sep 2019 11:05:22 -0500
From: Mike Ounsworth <>
To: Michael Richardson <>, Stephen Farrell <>
CC: "" <>
Thread-Topic: [EXTERNAL]Re: [Secdispatch] Problem statement for post-quantum multi-algorithm PKI
Thread-Index: AQHVaZ2KAX3VFnPP10y+CPHZx6ks6acqxkeAgAACXQCAAAcogIADqdfw
Date: Mon, 16 Sep 2019 16:05:22 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-CA, en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Secdispatch] [EXTERNAL]Re: 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 16:05:28 -0000

> Stephen Farrell <> wrote:

> I'd appreciate if someone could explain the specifics of the pressing issue here that requires us to not wait for e.g., the outcome of the NIST competition.

My Goal: multi-vendor interop on PQ certificates. 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?

- - -
Mike Ounsworth | Office: +1 (613) 270-2873

-----Original Message-----
From: Secdispatch <> On Behalf Of Michael Richardson
Sent: Friday, September 13, 2019 9:54 PM
To: Stephen Farrell <>
Subject: [EXTERNAL]Re: [Secdispatch] Problem statement for post-quantum multi-algorithm PKI

Stephen Farrell <> wrote:
    > On 14/09/2019 03:19, Michael Richardson wrote:
    >> > One might think we have plenty of time, given that Real Quantum >
    >> Computers are, more than likely, more than 10 years away, and even
    >> once > you have one, you cannot use your Quantum Computer to break the
    >> > authentication of recorded conversations.
    >> No, we really don't have plenty of time.  Some suggest that it is
    >> actually already rather *late*
    >> Long-lived devices (such as automobiles) are being designed today, for
    >> production in mid-2020s, and many will be on the road until 2040.

    > Count me unconvinced.

    > Either those devices will have s/w update or they're screwed already

If QM mechanisms take a lot more ram or a lot more bandwidth, then software updates aren't going to help them.
My understanding is that safety critical systems in cars are authenticating to each other over the internal buses (CAN, etc.) already.

    > even without requiring the putative existence of a quantum
    > computer. And we are discussing authentication here, mostly of origins
    > I guess, and not confidentiality, so post-facto attacks don't count
    > afaics.

    > I'd appreciate if someone could explain the specifics of the pressing
    > issue here that requires us to not wait for e.g., the outcome of the
    > NIST competition.

I'm not saying that we can't wait to finalize things.
I'm saying that we shouldn't wait for it to be finalized to start.

Can we support multiple signatures inside a certificate? I don't think so.
So what can we do?

]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]        |   ruby on rails    [