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

Douglas Stebila <> Tue, 17 September 2019 14:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 43CC012002E for <>; Tue, 17 Sep 2019 07:10:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 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, 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 QqgIMimIZc-K for <>; Tue, 17 Sep 2019 07:10:01 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8AA9E120878 for <>; Tue, 17 Sep 2019 07:10:00 -0700 (PDT)
Received: by with SMTP id w67so3019334lff.4 for <>; Tue, 17 Sep 2019 07:10:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=+2+WbSUzmcHJFR1vUrzykmoZkrCFJUQPYBx2PejqSrY=; b=c7dSnQjdvhRH/PXK6FdSeYY/LJb3YcFiXTaqKzXWy4Dt6HTImZJ/j/HdTqlB59iPjt zMUdqjcAnaPlHMIZVgL3GRFCXf6/FScpZo0OVPC/bKZSdwQgYfecRnA6/KdEOk9ti3jd RhNFv99c8nA0cSoCtLt78WBz0wSaaP14qDrxh+dYBbPizdpl1P/mSGPKMUVYPRq6jY5h e7cp46Y6I5bFRgaXQGRfYYS8tXm6vvZL51k7YNF8tZAEPG96o6mG0oypvD5Spwj1Qd6g 6TFrfCxwKuvsaZ6Bm8t9Yl9DG69rxHQaWRl1K2II8nUgjsFxKNprZWubmtsrMgYofGnX kBWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+2+WbSUzmcHJFR1vUrzykmoZkrCFJUQPYBx2PejqSrY=; b=rJgEJGdjAuE9TdL5b6uGwA2KSlhPNHz3fyVL2uRSEguWDf9w5DAI9mgl9casVf1yDq 53hecnWeo6HvqTmk9h6stDWGILg7MPMQtGHIHrk2Yu80DpdkbUqTsLOxQDql7p9kEH3r hdl46vg3YRg9ubgped7onjRjQMH7PTBaYk3Kb5ZEJjFDT+qLA9NQlN1eXRVDE9hIDgg5 YBabJbOc/5PUl1ndXdoVUTeRmIHB7UnO2XQ1hHdEOWGdFonR5c5LC09yEIrQ6xRdgGiA UpXJTl08AP0ogKrXQbcowpOqfaYY0r4pyHd3PyO1udBqP9u418+fMTXnSgNwCeRuw7X4 1bNg==
X-Gm-Message-State: APjAAAVMeqDRBGAXnDbNruT2kNNU30H6R9A0Ceo/CvdmkYX18MFlg+44 J+9V2JLhVRftozh0I+kIyklUc/TdSZbZ0mrywKNaMqcJ
X-Google-Smtp-Source: APXvYqx1pFL+LeNRjHB8ETKoOPL54Ffl5pKS62avVHrfWlcbHGBy2TI4BQK7ng1nAElW09I59Gn70IRGnF0vWwB/DQg=
X-Received: by 2002:ac2:5090:: with SMTP id f16mr2377120lfm.66.1568729398651; Tue, 17 Sep 2019 07:09:58 -0700 (PDT)
MIME-Version: 1.0
From: Douglas Stebila <>
Date: Tue, 17 Sep 2019 10:09:47 -0400
Message-ID: <>
Content-Type: multipart/alternative; boundary="0000000000008e31200592c0463d"
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 14:10:04 -0000

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.


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