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

Richard Barnes <> Tue, 17 September 2019 16:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 15B1A120916 for <>; Tue, 17 Sep 2019 09:14:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 nB7BHTJiVmhX for <>; Tue, 17 Sep 2019 09:14:36 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CCFE3120915 for <>; Tue, 17 Sep 2019 09:14:34 -0700 (PDT)
Received: by with SMTP id 21so3529595otj.11 for <>; Tue, 17 Sep 2019 09:14:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y4oGvFQ9ImiOEoGDSKj3WNBUfFNUARHmGbeCo9DZj5A=; b=bYqLQ7tHi0qtbahPHOGrQv2CbWIN9T48zY6vkO8WG3asxmXkcE77AU62mdOQMUwv0d 5ZRidp0eJemaxxAxn2MJCVSzj3UMQBGcunwx4ZTozaennh2GsjUwjSr+/hiWz0N9vEkm T1coYjv+B30KREunsJjVf8oBRneX1wGtaTsBRFFFCxPFZwtOpE/QjELCepr3cXTpKhK+ lcTAMqmLl92qrPsuIVpk9eoVfDsUvBPu2ZgN0a1Lu8t3Bpgabib9bC8tXadsYCdmvy+0 7YcgOHgVnRVYizZ1xdQc6mTaZYfwxnsQwMJiuEwPAYU/Clgqvu9BpZzC54zyXbFQ1szA SuOQ==
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=y4oGvFQ9ImiOEoGDSKj3WNBUfFNUARHmGbeCo9DZj5A=; b=onQIkCuFnDyOPKSshFKkLMXDO5IWlI4AcDFDbZBa95kn5BneHshNQJItHx7BxgQ/Um KYNrGHjo6FSMbGU/HQKl5jOmUJ8oOqZJ6AWQVmY3XMwYEZGzX3L9Utw3vdMvp4PZgObe VkNbe9ydPh11t1O6VIZJhJliq0u2JgXaoX4UChqszUQvGMFZJzMTEtM8kSU0GcPU0BQc b53Q0b3W39iJarj6apO319fmF0dkx/1bylkwTgYXo2yw7GEoFUhGzvqioE+cvjRagfL6 SirFOqXWMtC04pyXSihiR9biD6L08vu5vGuz+vhCAGHfLCuBf7nej6SWcLBtlOlAam1M HHLA==
X-Gm-Message-State: APjAAAXKYsAKZ4DXcmxXbbmCbJRvjQ+oCxfF7ntFQAdBTM1GMgEzsgPb B/AsgZDpmqx7BQJfODYNLPO53xLZpLBbdeo+aB5AiQ==
X-Google-Smtp-Source: APXvYqz9VLLiu0VT+aOzI2m5gvlSk8JLBef5E78pYaUjCud1VhoXVEiNI6L2e1dqHjRYoybpHU3ykPdueKkRT3NDO6s=
X-Received: by 2002:a05:6830:1e18:: with SMTP id s24mr3437480otr.93.1568736873983; Tue, 17 Sep 2019 09:14:33 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Richard Barnes <>
Date: Tue, 17 Sep 2019 12:14:22 -0400
Message-ID: <>
To: Douglas Stebila <>
Content-Type: multipart/alternative; boundary="0000000000001ef21a0592c20410"
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 16:14:39 -0000

+1 on the last point here -- we should get started on PQ stuff now
(including transition strategies), and should not waste time on unrelated
things, like replacing X.509.


On Tue, Sep 17, 2019 at 10:10 AM Douglas Stebila <> wrote:

> I'm a little late to the discussion, and new to the secdispatch mailing
> list, but hopefully not too late.  I think this is an important problem to
> address, and sooner rather than later.  NIST is still a few years away from
> having an outcome, but we can start laying the framework for how we'll use
> the resulting algorithms.  Although not everyone is convinced by "hybrid" /
> "multi-algorithm", there seems to be sufficient interest for it (e.g., the
> panel discussion at the NIST PQC standardization conference last month),
> that it's worth investing the time to investigate further.  I'm involved in
> a draft about hybrid key exchange in TLS for which there is no clear path,
> but lots of opinions and discussion worth having.  I'm also involved in an
> open source project ( where we are already wanting to
> prototype hybrid authentication in protocols relying on X.509, and we'd be
> happy to coordinate with others wanting to do so.  It would be really
> unfortunate if deployment of quantum-resistant algorithms was delayed even
> further because we spend 3-5 years struggling with network protocols and
> standards *after* NIST picks some algorithms, when we could have started
> that aspect earlier.
> Douglas
> On Wed, 11 September 2019, Mike Ounsworth <
>> wrote:
> Hi SecDispatch,
>> This got bounced here from LAMPS because the scope is potentially more
>> than a "limited" pkix change, and because this needs multi-WG visibility to
>> decide on a category of solution.
>> Background / history
>> --------------------
>> The Post-Quantum community (for example, surrounding the NIST PQC
>> competition), is pushing for "hybridized" crypto that combines RSA/ECC with
>> new primitives in order to hedge our bets against both quantum adversaries,
>> and also algorithmic / mathematical breaks of the new primitives.
>> A year and a half ago, a draft was put to LAMPS for putting PQ public key
>> and signatures into X.509v3 extensions. This draft has been allowed to
>> expire, but is being pursued at the ITU.
>> Earlier this year, a new draft was put to LAMPS for defining "composite"
>> public key and signature algorithms that, essentially, concatenate multiple
>> crypto algorithms into a single key or signature octet string. This draft
>> stalled in LAMPS over whether it is the correct overall approach.
>> Now I'm taking a step back and submitting a draft that acts as a
>> semi-formal problem statement, and an overview of the three main categories
>> of solutions.
>> My Opinion
>> ----------
>> Personally, I'm fairly agnostic to the chosen solution, but feel that we
>> need some kind of standard(s) around the post-quantum transition for
>> certificates and PKI. Personally, I feel that Composite is mature enough as
>> an idea to standardize as a tool in our toolbox for contexts where it makes
>> sense, even if a different mechanism is preferred for TLS and IPSEC/IKE.
>> Requested action from SECDISPATCH
>> ---------------------------------
>> 1. Feedback on the problem statement draft.
>> 2. Discussion of how to progress this.
>> PS I'm a new IETF'er, please be gentle :P
>> Thanks,
>> - - -
>> Mike Ounsworth | Software Security Architect
>> Entrust Datacard
> _______________________________________________
> Secdispatch mailing list