Subject: Re: [Secdispatch] [EXTERNAL]Re: Clarification Question for the Comment from Eric Rescorla (

From: Mike Ounsworth <[email-masked]>
Date: Mon, 9 Dec 2019 01:46:06 +0000

Hi Ekr, Max, Stephen,

We tried to design the proposed CompositeCrypto solution to be as generic and general as possible. During design, we wanted something that would work “generically well” across all ASN.1-based use-cases: PKIX (X.509, CRL, CMP, CMS S/MIME), OCSP , PKCS#?, PIV smart cards, code-signing, etc.

As Max said, it’s certainly possibly to design a more elegant solution by tailoring it to one use-case (for example by considering mechanisms available in a negotiated protocol). However, as companies who implement general-purpose Certificate Authorities, we’re looking for a more one-size-fits-most solution.

If WebPKI and CA/B Forum wants to take more time -- possibly even waiting out this problem – I hope that doesn’t preclude a push for a more immediate solution.

As for “why now”: Max has spoken at length about DOCSIS cable modems who want to begin deploying multi-algorithm-capable devices, like now. There are also other closed PKI environments (think heterogenous corporate PKIs providing certs for email, physical building access, Windows smart-card login, etc) where the customer-demanded timelines for classical+PQ solutions are too short to wait for each problem domain to standardize an optimized multi-alg cert standard (plus think of the headache if we fracture into dozens of different cert formats!).

As you say Ekr, maybe the solution is to use hash-based until we’re ready to migrate wholesale to a single NIST-crowned algorithm, but this is not the opinion that I’m hearing from the community around the NIST PQC, nor from my customers who want greater agility, not more restrictions. Hence this generic and flexible CompositeCrypto draft.

TL;DR: CompositeCrypto may not be the forever solution for all use-cases, but it would give us something we can start using soon as a transition mechanism, that we have confidence will be relatively problem-free across the breadth of PKI problem spaces.

- - -
Mike Ounsworth

From: Secdispatch <[email-masked]> On Behalf Of Eric Rescorla
Sent: Wednesday, November 20, 2019 1:29 AM
To: Dr. Pala <[email-masked]>
Cc: IETF SecDispatch <[email-masked]>; Stephen Farrell <[email-masked]>
Subject: [EXTERNAL]Re: [Secdispatch] Clarification Question for the Comment from Eric Rescorla (

WARNING: This email originated outside of Entrust Datacard.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
Hi Max,

I'm not presently taking a position on whether this work should proceed in a general matter; I haven't thought it through enough to have an opinion.

What I was trying to say in the meeting is that I don't think this is probably to be of much use in the WebPKI at this time.

-Ekr

On Tue, Nov 19, 2019 at 11:22 PM Dr. Pala <[email-masked]<mailto:[email-masked]>> wrote:

Hi Stephen, all,

I just want to add a quick consideration here. We work with hardware that is deployed at the customer's homes, offices, etc. When planning for our innovation to hit the networks, we need to plan years in advance - this is not something we deal with in universities, but, I assure you, it requires a lot more planning than you might be used to.

I do disagree with the fact that what we are doing doesn't really help that much. The proposed approach does provide a solution that, although it might not be optimized, it works.

Other solutions might come afterwards that provide (probably more complex) optimized paths (maybe TLS 2.0 will be quite different because its design will cover the new design requirements). Another possibility is that application specific would define their own code points: the "CompositCrypto" algorithm OID will allow to combine any algorithms. Applications can then define their own code-points that they accept by simply defining the appropriate OID for the algorithm identifer. For example, when and if TLS, for example, would like to define its own combination of algorithms, a set of specific code-points can be defined for that.

Coming back to delaying the work - I think it is wrong and I would like to understand why you think it is a good idea.

  *   We have the interest of an industry sector
  *   Plus, there has been support on the MLs for not delaying the work any further
  *   Plus, this work is presented by a committed set of Companies that have real interest in using this technology to protect the PKIs that secure the internet connectivity for hundreds of millions of users.
  *   Plus, the problem has been already addressed in other institutions (ITU-T) - thus indicating that IETF is falling behind on this topic.
  *   Plus, we are in contact with NIST to possibly collaborate on real-world deployment of QRC by using Composite Crypto.

I think that blocking or stalling this work within the IETF does not make any sense. If there are other competing/compelling proposals, please let's talk about that and find a common solution we standardize. I personally do not think that "Sometimes waiting is a little better" is a valid argument.

If you have technical reasons as to why this work shall not proceed, please let us know, we want to deploy the best solution possible.

Thanks,
Max

On 11/20/19 9:33 AM, Stephen Farrell wrote:

On 19/11/2019 21:48, Eric Rescorla wrote:

But until we are prepared to do that, then defining the

protocol syntax doesn't really help that much.

+1

Sometimes waiting a bit is better:-)

S.
--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
[OpenCA Logo]

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 9 Dec 2019 02:03:54 +0000

Hiya,

Cutting to the nub of my concern...

On 09/12/2019 01:46, Mike Ounsworth wrote:
> I hope that doesn’t preclude a push for a more immediate solution.

ISTM the "push" is less for a solution than for
understandably attempting to corner a market. I
don't think such attempts are "bad" things, but
I do think following 'em is more likely unwise.

Sorry if I've missed it, but who do we have that
is calling for a post-quantum PKI solution to be
developed now, but who is not promoting one such?

Thanks,
S.

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Thu, 12 Dec 2019 16:32:40 +0000

Hi,

> Sorry if I've missed it, but who do we have that is calling for a post-quantum PKI solution to be developed now, but who is not promoting one such?

We (Cisco) will need PQ PKI (not WebPKI) solution for image signing. When talking about chips that are designed now and will live in the field for decades, we would like to design today instead of wait for 2030. Note we are spending (not making) money on PKI, so we are not trying to corner a market.

I have talked to another vendor interested in them to sign its OS but I will not speak for them. I have also talked to at least one HSM vendor that has some clients asking for PQ PKI support to be added in their HSM but I will not speak for them either. I don't think any of these use-cases are trying to corner a market.

Panos

-----Original Message-----
From: Secdispatch <[email-masked]> On Behalf Of Stephen Farrell
Sent: Sunday, December 08, 2019 9:04 PM
To: Mike Ounsworth <[email-masked]>; Eric Rescorla <[email-masked]>; Dr. Pala <[email-masked]>
Cc: IETF SecDispatch <[email-masked]>
Subject: Re: [Secdispatch] [EXTERNAL]Re: Clarification Question for the Comment from Eric Rescorla (

Hiya,

> I hope that doesn’t preclude a push for a more immediate solution.

ISTM the "push" is less for a solution than for understandably attempting to corner a market. I don't think such attempts are "bad" things, but I do think following 'em is more likely unwise.

Sorry if I've missed it, but who do we have that is calling for a post-quantum PKI solution to be developed now, but who is not promoting one such?

Thanks,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Dec 2019 16:50:02 +0000

Hiya,

On 12/12/2019 16:32, Panos Kampanakis (pkampana) wrote:
> Hi,
> 
>> Sorry if I've missed it, but who do we have that is calling for a
>> post-quantum PKI solution to be developed now, but who is not
>> promoting one such?
> 
> We (Cisco) will need PQ PKI (not WebPKI) solution for image signing.
> When talking about chips that are designed now and will live in the
> field for decades, we would like to design today instead of wait for
> 2030. 

Thanks. It's not at all clear to me that data integrity nor
origin authentication in that timeframe ought be tied to
x.509 certificates at all. (Except for legacy algs/keys
where there's nothing to do.) Or do you envisage using other
approaches instead or as well when you say PKI? Personally,
I'd guess some kind of manifest based approach would be
better, maybe starting from cose or something. I would
be supportive of exploratory work in that space.

But adding multiple key/alg combinations alongside classical
algs/keys into x.509 certificates would create so many new
failure modes for all libraries that handle x.509 that it
seems generally unwise to me. (The failure modes for such
libraries have always been horrible, making 'em worse is
not a plan I'd warm to;-)

> Note we are spending (not making) money on PKI, so we are not
> trying to corner a market.

Fair enough that "corner a market" was a bit pejorative.
Apologies for that.

I'm just not at all convinced that trying to define how
to handle PQ algorithms in x.509 is at all worthwhile
now, especially before we have an outcome from the NIST
competition. Once we do have a standard set of algorithms
that people want to use (bearing in mind how sha-3 has
not set the world alight) then defining OIDs for those
would be fine, and fairly straightforward, but starting
now down a path that leads to x.509 certificates that
contain combinations of keys/algs in one cert seems like
a terrible plan to me.

Cheers,
S.

> I have talked to another vendor interested in them to sign its OS but
> I will not speak for them. I have also talked to at least one HSM
> vendor that has some clients asking for PQ PKI support to be added in
> their HSM but I will not speak for them either. I don't think any of
> these use-cases are trying to corner a market.
> 
> Panos
> 
> 
> -----Original Message----- From: Secdispatch
> <[email-masked]> On Behalf Of Stephen Farrell Sent:
> Sunday, December 08, 2019 9:04 PM To: Mike Ounsworth
> <[email-masked]>; Eric Rescorla <[email-masked]>;
> Dr. Pala <[email-masked]> Cc: IETF SecDispatch
> <[email-masked]> Subject: Re: [Secdispatch] [EXTERNAL]Re:
> Clarification Question for the Comment from Eric Rescorla (
> 
> 
> Hiya,
> 
> ISTM the "push" is less for a solution than for understandably
> attempting to corner a market. I don't think such attempts are "bad"
> things, but I do think following 'em is more likely unwise.
> 
> Sorry if I've missed it, but who do we have that is calling for a
> post-quantum PKI solution to be developed now, but who is not
> promoting one such?
> 
> Thanks, S. _______________________________________________ 
> Secdispatch mailing list [email-masked] 
> https://www.ietf.org/mailman/listinfo/secdispatch
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 12 Dec 2019 08:52:18 -0800

On Thu, Dec 12, 2019 at 8:33 AM Panos Kampanakis (pkampana) <
[email-masked]> wrote:

> post-quantum PKI solution to be developed now, but who is not promoting one
> such?
>
> We (Cisco) will need PQ PKI (not WebPKI) solution for image signing. When
> talking about chips that are designed now and will live in the field for
> decades, we would like to design today instead of wait for 2030. Note we
> are spending (not making) money on PKI, so we are not trying to corner a
> market.
>

Is there a reason why you don't want to do hash signatures?

-Ekr

I have talked to another vendor interested in them to sign its OS but I
> will not speak for them. I have also talked to at least one HSM vendor that
> has some clients asking for PQ PKI support to be added in their HSM but I
> will not speak for them either. I don't think any of these use-cases are
> To: Mike Ounsworth <[email-masked]>; Eric Rescorla <
> [email-masked]>; Dr. Pala <[email-masked]>
> ISTM the "push" is less for a solution than for understandably attempting
> to corner a market. I don't think such attempts are "bad" things, but I do
> think following 'em is more likely unwise.
>
> post-quantum PKI solution to be developed now, but who is not promoting one
> such?
>
> Thanks,
> S.
> _______________________________________________
> Secdispatch mailing list
> [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Dec 2019 17:06:55 +0000

> Is there a reason why you don't want to do hash signatures?

A good question. I'll also note that the mandatory
notAfter field in x.509 (which was always a mistake;-)
becomes a semantically misleading footgun with stateful
signatures. So you can't just use those algs in x.509
without lots and lots of likely-unexpected cascading
changes. (Changes that don't seem worthwhile to me.)

Cheers,
S.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 12 Dec 2019 16:32:26 -0500

> We (Cisco) will need PQ PKI (not WebPKI) solution for image
    > signing. When talking about chips that are designed now and will live
    > in the field for decades, we would like to design today instead of wait
    > for 2030. Note we are spending (not making) money on PKI, so we are not

As a variation of what EKR asked, you are asking for PQ-PKI, but your use
case is image signing.

I can see why having a set of chainable signed objects (i.e. a PKI) would
more useful than just a hash-based signature, if you can do it simply.

It seems like draft-ietf-cose-hash-sig-09 plus draft-birkholz-core-coid might
be useful here.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Fri, 13 Dec 2019 02:56:24 +0000

Hi Ekr, Stephen, Mike,

> As a variation of what EKR asked, you are asking for PQ-PKI, but your use case is image signing.

UEFI Secure Boot (in essence what I meant by image singing)  uses a PKI architecture. There is a Product Key PK (root CA) that establishes a trust relationship between the platform owner and the platform firmware. The PK signs KEKs which established a trust relationship between the platform firmware and the operating system. These are mostly in X.509 today. More in [2].

> Is there a reason why you don't want to do hash signatures?

HBS indeed looks like the best option for this usecase. Not necessarily stateful. We have some preliminary analysis on this is in Section 3 in [1]. More to come soon.

But we can’t go directly to pure HBS because already deployed machines in the field will not boot at all and upgrading BIOS is not simple. Also, we can’t go to pure HBS because it will not be FIPS approved even after we have a standardized PQ option. So, we have to do some sort of composite RSA+post-quantum (NIST has put out a statement that says that a composite will still be FIPS approved if the classical part is). The FIPS argument is important. Waiting for PQ standardization is one thing, but FIPS approval will take even longer and until then we (Cisco) want to do some sort of composite before then.

Note that I am not interested in getting an X.509 OID for RSA+HBS, I want a definition of how composite would work so I can establish the requirements for these future chips supporting composite verification.

> It's not at all clear to me that data integrity nor origin authentication in that timeframe ought be tied to x.509 certificates at all.

Stephen’s comment about not doing it in X.509 is valid. We could use a composite blob and use it in our own custom way. Two issues with that:

  1.  UEFI chains of trust have been moving to X.509 and to CMS/PKCS#7 for the sw signatures. I am not claiming there are no custom keys/signature formats nowhere, but most UEFI vendors have been moving away from them. So going to custom key representations or COSE would be a step backwards or sideways.
  2.  Also OEM vendors that include sig verification in their chips or FPGAs show preference in well-defined specs probably because they can reuse them for other usecases.
That is why we (Cisco) would prefer to see a standard way of doing composite sigs for UEFI (in X.509 and in CMS to be honest) instead of defining our own. We probably don’t want to solve this many times, once by each vendor, once in CMS, once UEFI PKI.

I totally appreciate the counter-argument about complexity and potential cans of worms, but I am afraid vendors will have to address this either individually or as a group. And my argument would doing it as a group.

Rgs,
Panos

[1] https://eprint.iacr.org/2019/1276.pdf
[2] https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance

From: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, December 12, 2019 11:52 AM
To: Panos Kampanakis (pkampana) <[email-masked]<mailto:[email-masked]>>
Cc: Stephen Farrell <[email-masked]<mailto:[email-masked]>>; IETF SecDispatch <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Secdispatch] [EXTERNAL]Re: Clarification Question for the Comment from Eric Rescorla (

On Thu, Dec 12, 2019 at 8:33 AM Panos Kampanakis (pkampana) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

-Ekr

Panos

-----Original Message-----
From: Secdispatch <[email-masked]<mailto:[email-masked]>> On Behalf Of Stephen Farrell
Sent: Sunday, December 08, 2019 9:04 PM
To: Mike Ounsworth <[email-masked]<mailto:[email-masked]>>; Eric Rescorla <[email-masked]<mailto:[email-masked]>>; Dr. Pala <[email-masked]<mailto:[email-masked]>>
Cc: IETF SecDispatch <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Secdispatch] [EXTERNAL]Re: Clarification Question for the Comment from Eric Rescorla (

Hiya,

Thanks,
S.
_______________________________________________
Secdispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/secdispatch

---

From: Mike Ounsworth <[email-masked]>
Date: Thu, 19 Dec 2019 16:09:49 +0000

Thanks Panos for laying out the use-cases. I think you hit a bit one on the head: FIPS approval. On 2019-10-30, NIST published a PQC FAQ that includes a call for hybrid modes for both key exchange and signatures.
https://csrc.nist.gov/Projects/Post-Quantum-Cryptography/faqs
draft-ounsworth-pq-composite-sigs intends to be the “obvious” implementation of NIST’s call for hybrid modes.

One place that we differ from NIST’s call is this point in the FAQ:

> The mode is valid if and only if both signatures are valid.

One of the design requirements that we’ve been working with is the one pushed by Max Pala / CableLabs; deploy devices in the field today that understand the hybrid pub key / signature format, but do not necessarily have an implementation of the PQ algorithm (or have an older, incompatible, implementation of the PQ alg while the NIST PQC is still shaking out mathematical or implementation vulnerabilities).

As to the philosophical debate about “Keep X.509 or go to something new?”, note that draft-ounsworth aims to define composite public key and signature formats that, if we’ve done it right, are compatible with any ASN.1 protocol. This draft is intentionally decoupled from, but can be used by, X.509.  The goal here is not to

Re: hash-based signatures: For a CA vendor – whether providing publicly-trusted services, or on-prem software -- product capabilities are driven by the industry; if the industry is happy with pure hash-based PKI during the transition period, then I agree that hybrid modes are unnecessary. However, that’s not what I’m seeing: the HBS schemes currently available in IETF are all stateful, and 1) NIST’s SP 800-208-draft says “Stateful HBS schemes are not suitable for general use because they require careful state management that is often difficult to assure”, and 2) chats I’ve had with Ryan Sleevi and Adam Langley who seem skeptical that all CA operators (public, private, corporate, etc), can responsibly manage a stateful private key. 3) Earlier this year, Panos had been pushing for publicly-trusted HSB root CAs, but dropped it on the point that, once you have a stateful HBS root CA, what do you do with it? You don’t really want end entities (TLS servers, the S/MIME client on your phone, PIV cards, etc) using stateful keys.
So maybe the market will be satisfied with HBS-only PKIs for some use-cases, but I maintain that we should standardize a fully algorithm-agnostic hybrid mechanism anyway.

PS - I’ll take your bait on the “corner the market” comment; IMHO a PKI is useless if its core functionality – public keys and signatures --do not interoperate with other vendors. No cornering of the market is intended, simply looking for a simple-ish solution quickly-ish.

---
Mike Ounsworth
Software Security Architect, Entrust Datacard

From: Secdispatch <[email-masked]> On Behalf Of Panos Kampanakis (pkampana)
Sent: December 12, 2019 9:56 PM
To: Eric Rescorla <[email-masked]>; Stephen Farrell <[email-masked]>; Michael Richardson <[email-masked]>
Cc: IETF SecDispatch <[email-masked]>
Subject: Re: [Secdispatch] [EXTERNAL]Re: Clarification Question for the Comment from Eric Rescorla (

Hi Ekr, Stephen, Mike,

Rgs,
Panos

-Ekr

Panos

-----Original Message-----
From: Secdispatch <[email-masked]<mailto:[email-masked]>> On Behalf Of Stephen Farrell
Sent: Sunday, December 08, 2019 9:04 PM
To: Mike Ounsworth <[email-masked]<mailto:[email-masked]>>; Eric Rescorla <[email-masked]<mailto:[email-masked]>>; Dr. Pala <[email-masked]<mailto:[email-masked]>>
Cc: IETF SecDispatch <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Secdispatch] [EXTERNAL]Re: Clarification Question for the Comment from Eric Rescorla (

Hiya,

Thanks,
S.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 21 Dec 2019 17:46:30 -0500

Panos Kampanakis (pkampana) <[email-masked]> wrote:
    > UEFI Secure Boot (in essence what I meant by image singing) uses a PKI
    > architecture. There is a Product Key PK (root CA) that establishes a
    > trust relationship between the platform owner and the platform
    > firmware. The PK signs KEKs which established a trust relationship
    > between the platform firmware and the operating system. These are
    > mostly in X.509 today. More in [2].

    > HBS indeed looks like the best option for this usecase. Not necessarily
    > stateful. We have some preliminary analysis on this is in Section 3 in
    > [1].  More to come soon.

    > But we can’t go directly to pure HBS because already deployed machines
    > in the field will not boot at all and upgrading BIOS is not
    > simple. Also, we can’t go to pure HBS because it will not be FIPS
    > approved even after we have a standardized PQ option. So, we have to do
    > some sort of composite RSA+post-quantum (NIST has put out a statement
    > that says that a composite will still be FIPS approved if the classical
    > part is). The FIPS argument is important. Waiting for PQ
    > standardization is one thing, but FIPS approval will take even longer
    > and until then we (Cisco) want to do some sort of composite before
    > then.

okay, I understand now.

You need to have a structure that makes use of all the existing, and
previously validated FIPS mechanisms and structures, but which adds a
post-quantum signature *in addition*.

It seems that such a solution needs to live within the ASN.1/DER-encoded PKIX
rules.   There have been proposals to add a HBS, and the hash-public-keys as
an extension in a certificate, which I think is really ugly, but would work.

I seem to recall a conversation at IETF106 about whether such a thing should
live within the certificate structure, or should wrap it.  It seems that you
need it to live within the certificate structure, and needs to provide a
parallel signature chain.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Carrick Bartle <[email-masked]>
Date: Mon, 23 Dec 2019 20:38:46 -0800

> WebPKI doesn't want it

How can it be true that it's too early to start developing a protocol for composite keys and signatures for Web PKI when Cloudflare and Google have already finished a round of experiments with hybrid key exchanges? Maybe I'm reading too much into it, but the existence of those experiments suggested to me that the need for hybrid/composite implementations was imminent. (I understand that the draft in question concerns signatures, not key exchanges, but apparently there isn't even a draft for the latter yet.)

If not now, when? After NIST crowns a winner? I don't see why it's necessary to wait that long given that the proposed solutions are algorithm-independent. And since the standardization process takes a while, won't waiting until then mean that there won't be a standard until after it's needed?

Carrick

> On Nov 19, 2019, at 11:37 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Tue, Nov 19, 2019 at 11:34 PM Salz, Rich <[email-masked] <mailto:[email-masked]>> wrote:
> I agree with that.
> But of course that’s not a “veto” on doing this work, which OF COURSE you are not saying.
> 
> 
> Agreed. I think the relevant question is if there is enough demand, so just because WebPKI doesn't want it doesn't mean that someone doesn't.
> 
> -Ekr
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/secdispatch <https://www.ietf.org/mailman/listinfo/secdispatch>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/secdispatch <https://www.ietf.org/mailman/listinfo/secdispatch>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 25 Dec 2019 17:57:19 -0800

On Mon, Dec 23, 2019 at 8:38 PM Carrick Bartle <[email-masked]>
wrote:
> How can it be true that it's too early to start developing a protocol
> for composite keys and signatures for Web PKI when Cloudflare and
> Google have already finished a round of experiments with composite key
> exchanges? Maybe I'm reading too much into it, but the existence of
> those experiments suggested to me that the need for composite/composite
> implementations was imminent. (I understand that the draft in question
> concerns signatures, not key exchanges, but apparently there isn't
> even a draft for the latter yet.)

ISTM that these cases are pretty different, in a number of respects.

First, the primary rationale for doing composite key exchange now is to
defend against retrospective attacks in case a quantum computer exists
in the future. In this setting, it isn't critically important to have
the PQ algorithm be the one we eventually land on, because each
connection is separately negotiated and as long as the PQ algorithm
has some security, you're getting benegit,.

The primary rationale for doing PQ authentication now (or for that
matter composite authentication) is to be prepared for the day when QC
exists and we are therefore unable to rely on classical
algorithms. However, it's not useful to be prepared in that fashion
unless the algorithm that you are deploying is the one that is
eventually selected, because otherwise you just have to start over
once the selection is made.

Moreover, in order to be truly prepared, what you need isn't
principally relying party deployment, but rather authenticating party
(in the case of the WebPKI, server-side) deployment. The reason for
this is that in the world where a QC exists, you don't have protection
until the relying party refuses to accept the classical credential
[0], and at present, any client which does so will effectively be
unable to communicate. And in order to make that happen, relying
parties will have to require a post-quantum algorithm (most likely as
a composite) and that's something I don't expect them to be willing to do
until there's widespread agreement on what that algorithm should be.

> If not now, when? After NIST crowns a winner? I don't see why it's
> necessary to wait that long given that the proposed solutions are
> algorithm-independent. And since the standardization process takes a
> while, won't waiting until then mean that there won't be a standard
> until after it's needed?

No, i don't think so.

For the reasons above, ISTM that real deployment will have to wait
until we have a selected algorithm. One could, as you suggest, deploy
some sort of multi-algorithm container, but IMO we will be far better
off just deploying new composite algorithms as if the were single
new algorithms, in the same way as we have done for key establishment.

For this reason, I think we ought to wait until there is a consensus
PQ signature algorithm, at least for the WebPKI.

-Ekr

[0] This is why this kind of composite isn't helpful in the world
where a secret QC exists not.