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

Phillip Hallam-Baker <> Wed, 18 September 2019 12:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0774A1201E5 for <>; Wed, 18 Sep 2019 05:09:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.915
X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 p2D4B2BEm82F for <>; Wed, 18 Sep 2019 05:09:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DE15C12004D for <>; Wed, 18 Sep 2019 05:09:07 -0700 (PDT)
Received: by with SMTP id 67so6104465oto.3 for <>; Wed, 18 Sep 2019 05:09:07 -0700 (PDT)
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=e4BjRSdBY0hKe55a0YmC8uJeWDiAh0hyLmZBzVzFLEY=; b=kpGlBX2niCkvfprn9mHwbD4rt1sTHiqNMC2XNHCUCkN7RZkQRPHTBpcKykXytWSgMI ZPmJZC9/PrrTWRdN8lZtROB3FFxOWaYgTts/orauIHXbOlwMyMqkqGJ8wU/G+gHfEbDZ LY6mns5YE9kCLb3yygijVIwf/5lzOnFUWc30yS+efPBzvBm5dyMEwW1V9W0yod/cUI7Z 6/fiO4YfKdoBp0lu8oKVbr2wYCoJYBdJmVIttRNiJCJWrIit8bAgVyQKuOBZ819psE5D wRfzra6MJUV0PANWMTiHhfqD0uJ8lEA8cOCSld6RiowC7GB2MKYV41W59lvu0scYelGU 1mJQ==
X-Gm-Message-State: APjAAAUqW90AaSQLt6YTWsb0N/wnmkPz+DZzYycFP0xcfaUjsBn/MacU 3+tIkw3oe6+SW4TbszzqcIhgHdeyaEIb3h/d3gs=
X-Google-Smtp-Source: APXvYqw9vAf08SMmhzQvBS5DJr0BiHgaxGUOVh2HIOR/NJbjdlL6X/ugYzuBwjUokfc5ea17SaXc/cghgFptnj++UDQ=
X-Received: by 2002:a9d:7d08:: with SMTP id v8mr2680368otn.231.1568808547204; Wed, 18 Sep 2019 05:09:07 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <6013.1568740878@localhost> <> <> <>
In-Reply-To: <>
From: Phillip Hallam-Baker <>
Date: Wed, 18 Sep 2019 08:08:55 -0400
Message-ID: <>
To: Stephen Farrell <>
Cc: Mike Ounsworth <>, Michael Richardson <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000002d44b50592d2b489"
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: Wed, 18 Sep 2019 12:09:10 -0000


It looks fairly certain that PQ algorithms will either be a drop in
replacement requiring no changes or require so much change that PKIX is
pretty much irrelevant. We are not going to be using a Kohnfelder
architecture to support a PKI based on stateful signatures.

The two technologies we are going to need to revisit are Needham-Schroeder
(e.g. Kerberos) and Haber-Stornetta (e.g. Blockchain)

We do have some experience with BlockChain type technologies. Certificate
Transparency for one. But I don't feel like trying to build on top of that
so I wrote a separate BlockChain type technology for the Mathematical Mesh
which is basically Merkle Tree in JSON using JOSE as the crypto base. It
also builds in some of the same ideas from SAML.

The latest draft is here:

This is not designed as a PQ infrastructure but it does have some (much?)
of the infrastructure that you would want for building blocks for PQ.

On Tue, Sep 17, 2019 at 5:17 PM Stephen Farrell <>

> Hiya,
> On 17/09/2019 21:30, Mike Ounsworth wrote:
> >
> > It sounds like what you're proposing will end up lining up with the
> > still-yet-to-be-defined solution of "just use multiple cert chains",
> Nope, sorry for being unclear. I'm coming around to arguing to
> not bother with using x.509 at all any weird new PQ stuff, (like
> stateful sigs or where values are big enough to cause protocol
> problems in places x.509 is currently used), and to definitely
> not embed multiple key/alg stuff inside x.509. Existing x.509
> libraries could then continue to be used really unmodified (so
> no change to what's often pretty flakey cert validation logic,
> only crypto APIs) with current algs or where some PQ alg reall
> fits the current model well enough. In addition, I'd argue to
> wait 'till NIST are done to start in any detailed way. Hope
> that's clearer.
> Cheers,
> S.
> _______________________________________________
> Secdispatch mailing list