Subject: [Secdispatch] Can Composite sigs move back to LAMPS?

From: Mike Ounsworth <[email-masked]>
Date: Thu, 16 Jan 2020 19:13:13 +0000

Following up on in-room discussions at 106, and the ensuing list discussions, I'd like to ask for confirmation of the following points:

1. There is enough interest in an obvious-and-straightforward implementation of composite signatures to continue working on it?
   1a. The current draft for this is draft-ounsworth-pq-composite-sigs-02

2. SecDispatch is assigning this back to LAMPS?
   2a. The current draft might not be the most obvious-and-straightforward implementation; we're willing to simplify until it's in-scope for LAMPS.

---
Mike Ounsworth
Software Security Architect, Entrust Datacard

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 Jan 2020 19:27:54 +0000

Hiya,

I'm guessing it'll be no surprise that I reckon that we
ought not adopt either piece of work at this time (sorry
for being so predictablel;-) I continue to think waiting
'till we know more is wiser.

I'd also note that CVE-2020-0601 may (when full details
emerge) provide very direct evidence that standardising
cryptographic parameter representations ahead of real
understanding of the algorithms and their implementations
and real uses can be a bad plan with implications that
only hit decades later.

Even if it turns out that (some years later) RFC5280 got
it right in saying "don't do that", I'd argue earlier
ASN.1 modules (whether from IETF, ITU-T, ANSI or whomever)
got it wrong in ever providing a way to encode custom
curve parameters.

Regards,
S.

On 16/01/2020 19:13, Mike Ounsworth wrote:
> Following up on in-room discussions at 106, and the ensuing list
> discussions, I'd like to ask for confirmation of the following
> points:
> 
> 1. There is enough interest in an obvious-and-straightforward
> implementation of composite signatures to continue working on it? 1a.
> The current draft for this is draft-ounsworth-pq-composite-sigs-02
> 
> 2. SecDispatch is assigning this back to LAMPS? 2a. The current draft
> might not be the most obvious-and-straightforward implementation;
> we're willing to simplify until it's in-scope for LAMPS.
> 
> --- Mike Ounsworth Software Security Architect, Entrust Datacard
> 
> _______________________________________________ Secdispatch mailing
> list [email-masked] 
> https://www.ietf.org/mailman/listinfo/secdispatch
>

---

From: "Markku-Juhani O. Saarinen" <[email-masked]>
Date: Thu, 16 Jan 2020 21:21:21 +0000

On Thu, Jan 16, 2020 at 7:13 PM Mike Ounsworth <
[email-masked]> wrote:

> discussions, I'd like to ask for confirmation of the following points:
>
> implementation of composite signatures to continue working on it?

I'd certainly like this to proceed as it the only document of this type
that is currently alive in IETF (as far as I know).

As everyone knows, the NIST PQC process will soon be in its final
third-round stretch and we're not the only vendor who is already quite
familiar with the various proposals, has implemented them, and are in the
process of making them commercially available in cooperation with PKI
vendors. We don't want to end up in a nightmare scenario where each vendor
pushing their own kind of dual/hybrid/composite/twin/double/mixed signature
solution of highly variable design quality.

In some ways IETF is perhaps behind the curve here as FIPS certification
guidelines are being created for exactly the types of technologies that
"draft-ounsworth-pq-composite-sigs-02" discusses. See e.g.
https://csrc.nist.gov/Projects/Post-Quantum-Cryptography/faqs#xisl "In
particular, a hybrid mode for signatures consists of two signatures. The
mode is valid if and only if both signatures are valid." Hence the need for
standardization of composite signatures.

Stephen Farrell referred to CVE-2020-0601 --  I don't see how composite
signatures is related to specific parameter representations. That has not
been proposed, apart from OID identifiers for a type of composite
signature. The composite can even be made up of ECC and RSA signatures. It
is just an abstraction intended to help with the transition to the next set
of standards, which is very much happening as it has been on e.g. the USG
roadmap at least since the CNSA announcement in 2015.

>    2a. The current draft might not be the most obvious-and-straightforward
> implementation; we're willing to simplify until it's in-scope for LAMPS.
>

This bouncing back and forth seems symptomatic of IETF. Those of use who
are working on this technology will just have to "follow the specification
around" if that happens.

Anyway let's keep working on it. I'd be even ready to help push it through
as "informational" on the strength of having interoperable industry
implementations. Currently the level of detail is not sufficient for that,
but we should be able to iterate enough detail in there if we do a little
bit of engineering interop. As to what is the most appropriate forum for
that, I'm open to suggestions.

Cheers,
- markku

Dr. Markku-Juhani O. Saarinen <[email-masked]> PQShield, Oxford UK.

---

From: Daniel Van Geest <[email-masked]>
Date: Thu, 16 Jan 2020 21:38:26 +0000

Hi Stephen,

On 2020-01-16, 7:28 PM, "Secdispatch on behalf of Stephen Farrell" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hiya,

[DVG] I think we can appreciate your consistency at least :-)

[DVG] I think you’ve hinted (or stated explicitly) at this before, but it
confuses me. draft-ounsworth-pq-composite-sigs does not attempt to
standardize the parameter representations of any cryptographic
algorithms.  It’s just a framework for combining other standardized
representations.  In the PQ case those are to be standardized
separately in the future.  This draft could just as well be used to
combine RSA and elliptic curve signatures.  I don’t want to put words
in Max Pala’s mouth, but he’s currently dealing with a newborn so
I will provisionally say I think combining classical algorithms using
this method is of interest to him.  Probably the draft should be
renamed to draft-ounsworth-composite-signatures, similarly to what
was done in IPSecME for a draft combining key agreement algorithms.
There’s nothing PQ-specific about either mechanism, but the efforts
are being made now in anticipation of these algorithms arrivals,
knowing how long the standardization process can take.

Thanks,

Daniel Van Geest

list [email-masked]<mailto:[email-masked]>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 Jan 2020 12:10:56 +0000

Hiya,

On 16/01/2020 21:38, Daniel Van Geest wrote:
> Hi Stephen,
> 
> On 2020-01-16, 7:28 PM, "Secdispatch on behalf of Stephen Farrell"
> <[email-masked]<mailto:[email-masked]> on
> behalf of
> [email-masked]<mailto:[email-masked]>> wrote:
> 
> Hiya,
> 
> I'm guessing it'll be no surprise that I reckon that we ought not
> adopt either piece of work at this time (sorry for being so
> predictablel;-) I continue to think waiting 'till we know more is
> wiser.
> 

You're welcome:-)

> I'd also note that CVE-2020-0601 may (when full details emerge)
> provide very direct evidence that standardising cryptographic
> parameter representations ahead of real understanding of the
> algorithms and their implementations and real uses can be a bad plan
> with implications that only hit decades later.
> 
> [DVG] I think you’ve hinted (or stated explicitly) at this before,
> but it confuses me. draft-ounsworth-pq-composite-sigs does not
> attempt to standardize the parameter representations of any
> cryptographic algorithms.  It’s just a framework for combining other
> standardized representations.  In the PQ case those are to be
> standardized separately in the future.  This draft could just as well
> be used to combine RSA and elliptic curve signatures. 

So I really don't see any benefit in a new complex way to
combine RSA and ECC signatures. I do see many costs and risks.
My conclusion is that this stuff could only really be useful
enough to justify the costs if we have PQ signature schemes
that are considered stable enough to deploy but where we
don't yet fully trust the algorithms to the point where we'd
be happy to depend solely on those new algorithms. In that
context, ISTM that creating the scope for CVE-20YY-NNNN
(analogous to CVE-2020-0601) is a very real risk among others
that were already mentioned earlier in discussion. (*)

Cheers,
S.

(*) I brought up CVE-2020-0601 not as a killer-argument that
summarises the entire thread, but because the CVE is new
information (even if we're still unsure of all the details)
and I don't recall that specific risk having come up in the
discussion so far.

> I don’t want
> to put words in Max Pala’s mouth, but he’s currently dealing with a
> newborn so I will provisionally say I think combining classical
> algorithms using this method is of interest to him.  Probably the
> draft should be renamed to draft-ounsworth-composite-signatures,
> similarly to what was done in IPSecME for a draft combining key
> agreement algorithms. There’s nothing PQ-specific about either
> mechanism, but the efforts are being made now in anticipation of
> these algorithms arrivals, knowing how long the standardization
> process can take.
> 
> Thanks,
> 
> Daniel Van Geest
> 
> 
> On 16/01/2020 19:13, Mike Ounsworth wrote: Following up on in-room
> discussions at 106, and the ensuing list discussions, I'd like to ask
> for confirmation of the following points: 1. There is enough interest
> in an obvious-and-straightforward implementation of composite
> signatures to continue working on it? 1a. The current draft for this
> is draft-ounsworth-pq-composite-sigs-02 2. SecDispatch is assigning
> this back to LAMPS? 2a. The current draft might not be the most
> obvious-and-straightforward implementation; we're willing to simplify
> until it's in-scope for LAMPS. --- Mike Ounsworth Software Security
> Architect, Entrust Datacard

---

From: "Markku-Juhani O. Saarinen" <[email-masked]>
Date: Fri, 17 Jan 2020 12:22:35 +0000

On Fri, Jan 17, 2020 at 12:11 PM Stephen Farrell <[email-masked]>
wrote:

> be happy to depend solely on those new algorithms.

Thanks for your support. That is exactly where we are and what the stated
purpose of draft-ounsworth-pq-composite-sigs-02 is.

Cheers,
- markku

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 Jan 2020 12:30:29 +0000

On 17/01/2020 12:22, Markku-Juhani O. Saarinen wrote:
> Thanks for your support. That is exactly where we are 

I hope it's clear I disagree with you - IMO the conditions
above are not satisfied today and I do not support adopting
such work at this time. Were I to guess and be optimistic
it might be worth re-considering the topic in a year or so.

S.

> and what the stated
> _______________________________________________
> Secdispatch mailing list
> [email-masked]

---

From: Mike Ounsworth <[email-masked]>
Date: Fri, 17 Jan 2020 17:54:25 +0000

> Were I to guess and be optimistic it might be worth re-considering the topic in a year or so.

Cool. In the meantime, we plan to keep working on the outstanding TODO decision points in the draft as more vendors approach us for interop testing. :-)

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

-----Original Message-----
From: Stephen Farrell <[email-masked]> 
Sent: January 17, 2020 6:30 AM
To: Markku-Juhani O. Saarinen <[email-masked]>
Cc: Daniel Van Geest <[email-masked]>; IETF SecDispatch <[email-masked]>; Mike Ounsworth <[email-masked]>
Subject: [EXTERNAL]Re: [Secdispatch] Can Composite sigs move back to LAMPS?

On 17/01/2020 12:22, Markku-Juhani O. Saarinen wrote:
>> enough to justify the costs if we have PQ signature schemes that are 
>> considered stable enough to deploy but where we don't yet fully trust 
>> the algorithms to the point where we'd be happy to depend solely on 
>> those new algorithms.
> 
> 

I hope it's clear I disagree with you - IMO the conditions above are not satisfied today and I do not support adopting such work at this time. Were I to guess and be optimistic it might be worth re-considering the topic in a year or so.

S.

---

From: Carrick Bartle <[email-masked]>
Date: Fri, 17 Jan 2020 10:08:02 -0800

From what I've gathered from the mailing list discussion on this topic (in particular, the lead time necessary for hardware), it strikes me that there is sufficient reason for this work to advance.

> On Jan 16, 2020, at 11:13 AM, Mike Ounsworth <[email-masked]> wrote:
>

---

From: John Gray <[email-masked]>
Date: Fri, 17 Jan 2020 18:15:53 +0000

Hi Stephen,

The reason why we are putting together this composite standard is because we believe we are in this position today.   If NIST  decides no Round 3 is needed, then we will know the PQ winners by June of this year.   Even if there is a Round 3, and no final set of PQ algorithms is declared until 2021 or 2022, we want to have a hybrid standard ready for us use.  We will need to implement, test, and interop and all these things take time and have to be done after there is a standard.  If we wait too long, it will be a free for all.   

There are already a small handful of stable PQ algorithms available to use today.   See RFC 8391 (XMSS) and RFC 8554 (LMS), so using a hybrid RSA or EC with XMSS or LMS in a composite form is already viable.  The choices are definitely few at this moment, but there are viable use-cases.   We want to give our customers peace of mind and transition to a post quantum world.  This standard will address customer anxiety and bridges the gap to a stable post quantum world.   It addresses the quantum threat verses algorithm scrutiny.  

Cheers,

John Gray
Software Architect, Entrust Datacard

-----Original Message-----
From: Secdispatch [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Friday, January 17, 2020 7:30 AM
To: Markku-Juhani O. Saarinen <[email-masked]>
Cc: Daniel Van Geest <[email-masked]>; IETF SecDispatch <[email-masked]>; Mike Ounsworth <[email-masked]>
Subject: [EXTERNAL]Re: [Secdispatch] Can Composite sigs move back to LAMPS?

S.

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 17 Jan 2020 21:32:57 +0300

Hi Stephen,

> I hope it's clear I disagree with you - IMO the conditions above are not
> satisfied today and I do not support adopting such work at this time. Were I
> to guess and be optimistic it might be worth re-considering the topic in a
> year or so.

Given the usual IETF performance, a year is a term just to launch a real work
and realize where to go. So, I think we should start doing it now to have
plenty of time and not to be in a hurry later.

Regards,
Valery.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 Jan 2020 20:06:13 +0000

Replying to a few mails at once, but ISTM this is starting
to get repetitive.

On 17/01/2020 18:15, John Gray wrote:
> Hi Stephen,
> 
> The reason why we are putting together this composite standard is 
> because we believe we are in this position today.   If NIST  decides 
> no Round 3 is needed, then we will know the PQ winners by June of 
> this year.   Even if there is a Round 3, and no final set of PQ 
> algorithms is declared until 2021 or 2022, we want to have a hybrid 
> standard ready for us use.  We will need to implement, test, and 
> interop and all these things take time and have to be done after 
> there is a standard.  If we wait too long, it will be a free for 
> all.

Right now there are too many algorithms to believe that
we'd have other than a free-for-all as those pushing one
or another try get their thing adopted. I'd also note
that NIST has a history or defining new parameterisations
after algorithm selection, so wouldn't be surprised if
that happened here too. I'd prefer we wait and see what
results from the NIST thing rather adopt work now in
the IETF. If people want to do work ahead of NIST then
that's of course fine, but adopting such work in the IETF
is asking us all to do work on this now, and I think that's
both risky and wasteful.

> 
> There are already a small handful of stable PQ algorithms available 
> to use today.   See RFC 8391 (XMSS) and RFC 8554 (LMS), so using a 
> hybrid RSA or EC with XMSS or LMS in a composite form is already 
> viable.  The choices are definitely few at this moment, but there
> are viable use-cases.

Stateful signature schemes such as those are not suited
for use in X.509 IMO, as was already raised on the list.
(And someone earlier claimed they wouldn't work for their
use-cases, so I'm confused as to whether the proponents
here do or don't want to include stateful signature
schemes.)

On 17/01/2020 17:54, Mike Ounsworth wrote:
> Cool. In the meantime, we plan to keep working on the outstanding 
> TODO decision points in the draft as more vendors approach us for 
> interop testing. :-)

I've no objection to people working on stuff. I am opposed
to the IETF prematurely adopting work in this space though.

On 17/01/2020 18:08, Carrick Bartle wrote:
> From what I've gathered from the mailing list discussion on this 
> topic (in particular, the lead time necessary for hardware), it 
> strikes me that there is sufficient reason for this work to advance.

My experience in the IETF is that ill-defined and less well
understood work takes longest. I think this matches that at
the moment. I'd suggest the proponents might be better
spending time on developing their work by implementing it
in open-source generic PKI libraries and applications so
that they can produce some non arm-waving evidence as to
what this does or doesn't break. (IMO, it'll turn out to
break a lot and change many lines of code, but who knows,
I may be wrong.)

On 17/01/2020 18:32, Valery Smyslov wrote:
> Given the usual IETF performance, a year is a term just to launch a 
> real work and realize where to go. So, I think we should start doing 
> it now to have plenty of time and not to be in a hurry later.

See above as to how to speed things up more effectively.
Additionally, the idea that waiting a year or so means
someone would have to "be in a hurry" seems questionable
to me.

Cheers,
S.

---

From: Mike Ounsworth <[email-masked]>
Date: Fri, 17 Jan 2020 22:17:21 +0000

Hi Stephen,

We may have a misunderstanding about what draft-ounsworth-pq-composite-sigs is trying to accomplish. 

Draft-ounsworth-pq-composite-sigs defines ASN.1 structures for carrying multiple SubjectPublicKeyInfo, AlgorithmIdentifier, and BIT STRING (signature values), in a way that will be drop-in for PKIX-like protocols.

You keep mentioning parameter sets and "what if they change?". I really don't see why that's relevant. Draft-ounsworth-pq-composite-sigs is algorithm-agnostic; orthogonal to the choice of algorithms by NIST or their encodings. 

If anything, I see your argument being in support of composite because a composite solution can help bridge across a param change, for example maybe by including one signature on each param set until all clients are upgraded. I wish such a mechanism had existed since the beginning of PKI; it would have helped for example with the SHA1 -> SHA2 migration as there are *still* PKI deployments with a handful of critical legacy clients that keep the entire ecosystem on SHA1. In fact, AFAIK Microsoft code-signing did exactly that by including both SHA1 and SHA2 signatures on binaries and letting the verifier pick their favourite during the transition period. Let's standardize this before we end up with a dozen proprietary ways of jamming 2+ signatures on things!

---

-----Original Message-----
From: Stephen Farrell <[email-masked]> 
Sent: January 17, 2020 2:06 PM
To: John Gray <[email-masked]>; Markku-Juhani O. Saarinen <[email-masked]>; IETF SecDispatch <[email-masked]>
Cc: Daniel Van Geest <[email-masked]>; Mike Ounsworth <[email-masked]>
Subject: Re: [EXTERNAL]Re: [Secdispatch] Can Composite sigs move back to LAMPS?

Replying to a few mails at once, but ISTM this is starting to get repetitive.

On 17/01/2020 18:15, John Gray wrote:
> interop and all these things take time and have to be done after there 
> is a standard.  If we wait too long, it will be a free for all.

Right now there are too many algorithms to believe that we'd have other than a free-for-all as those pushing one or another try get their thing adopted. I'd also note that NIST has a history or defining new parameterisations after algorithm selection, so wouldn't be surprised if that happened here too. I'd prefer we wait and see what results from the NIST thing rather adopt work now in the IETF. If people want to do work ahead of NIST then that's of course fine, but adopting such work in the IETF is asking us all to do work on this now, and I think that's both risky and wasteful.

> viable.  The choices are definitely few at this moment, but there are 
> viable use-cases.

Stateful signature schemes such as those are not suited for use in X.509 IMO, as was already raised on the list.
(And someone earlier claimed they wouldn't work for their use-cases, so I'm confused as to whether the proponents here do or don't want to include stateful signature
schemes.)

On 17/01/2020 17:54, Mike Ounsworth wrote:
> Cool. In the meantime, we plan to keep working on the outstanding TODO 
> decision points in the draft as more vendors approach us for interop 
> testing. :-)

I've no objection to people working on stuff. I am opposed to the IETF prematurely adopting work in this space though.

On 17/01/2020 18:08, Carrick Bartle wrote:
> From what I've gathered from the mailing list discussion on this topic 
> (in particular, the lead time necessary for hardware), it strikes me 
> that there is sufficient reason for this work to advance.

My experience in the IETF is that ill-defined and less well understood work takes longest. I think this matches that at the moment. I'd suggest the proponents might be better spending time on developing their work by implementing it in open-source generic PKI libraries and applications so that they can produce some non arm-waving evidence as to what this does or doesn't break. (IMO, it'll turn out to break a lot and change many lines of code, but who knows, I may be wrong.)

See above as to how to speed things up more effectively.
Additionally, the idea that waiting a year or so means someone would have to "be in a hurry" seems questionable to me.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 Jan 2020 22:21:39 +0000

On 17/01/2020 22:17, Mike Ounsworth wrote:
> You keep mentioning parameter sets and "what if they change?". I
> really don't see why that's relevant.
Running code. Introduction of new failure modes in already-
notoriously brittle code. It may be easy to write the ASN.1
module, but that's only a tiny bit of the work and (from
experience) easy to get wrong in the absence of real code.

S.

---

From: "Markku-Juhani O. Saarinen" <[email-masked]>
Date: Fri, 17 Jan 2020 23:04:53 +0000

> experience) easy to get wrong in the absence of real code.

Most people here know that we've had running code for "hybrid/composite
certificates" for years, e.g. an open one via OQS ( you go and play with
those certs at
https://github.com/open-quantum-safe/openssl/tree/OQS-OpenSSL_1_1_1-stable )
and a proprietary ones via Isara and DigiCert.

The problem is not that there is no running code, the problem is that there
is too much running code and it does not talk to each other due to lack of
IETF-supported standardization.

Anyway, as Mike noted, we'll just do the spec, interop with industry
partners and go from there.

Cheers,
- markku

---

From: Michael Richardson <[email-masked]>
Date: Sat, 18 Jan 2020 11:24:34 -0500

Mike Ounsworth <[email-masked]> wrote:
    > Draft-ounsworth-pq-composite-sigs defines ASN.1 structures for carrying
    > multiple SubjectPublicKeyInfo, AlgorithmIdentifier, and BIT STRING
    > (signature values), in a way that will be drop-in for PKIX-like
    > protocols.

    > You keep mentioning parameter sets and "what if they change?". I really
    > don't see why that's relevant. Draft-ounsworth-pq-composite-sigs is
    > algorithm-agnostic; orthogonal to the choice of algorithms by NIST or
    > their encodings.

In particular, it seems to me that we could add these multiple entries to
certificates, using dummy algorithms, and test them in the field against
existing browsers, web servers, IDS, firewalls, etc.

We know that this system has to work with systems that don't understand it
yet.

I don't know if LAMPS is the right group though.
It feels like it needs a new WG.

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

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 18 Jan 2020 11:58:39 -0800

On Sat, Jan 18, 2020 at 8:24 AM Michael Richardson <[email-masked]>
wrote:

> really

It's not quite clear to me how this would work. As I understand it, this
involves replacing the existing public keys and signatures, in which case
they won't be acceptable to any Web browser (and you in fact won't be able
to get BR-compliant certs)....

-Ekr

---

From: Michael Richardson <[email-masked]>
Date: Sat, 18 Jan 2020 16:13:50 -0500

Eric Rescorla <[email-masked]> wrote:
    mcr> In particular, it seems to me that we could add these multiple
    mcr> entries to
    mcr> certificates, using dummy algorithms, and test them in the field
    mcr> against
    mcr> existing browsers, web servers, IDS, firewalls, etc.

    > It's not quite clear to me how this would work. As I understand it,
    > this involves replacing the existing public keys and signatures, in
    > which case they won't be acceptable to any Web browser (and you in
    > fact won't be able to get BR-compliant certs)....

No, it involves two sets of signatures.
The traditional set and the new, yet-to-be-precisely-defined set.

It could be that CAFORUM rules would presently prevent these certificates
From going into production, and during an experiment, that would be okay, I
think.

The reason to start this work now is to wring out the obsticales such as
BR/CABFORUM rules that would prevent/slow-down adoption.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 18 Jan 2020 13:31:22 -0800

> The traditional set and the new, yet-to-be-precisely-defined set.

Yes, but I had understood these tbe encoded on the wire as if they were a
new signature algorithm, with the result that such a certificate would not
be verifiable by an existing client.

Perhaps we should resolve this question first.

-Ekr

---

From: Michael Richardson <[email-masked]>
Date: Sun, 19 Jan 2020 11:59:18 -0500

Eric Rescorla <[email-masked]> wrote:
    mcr> In particular, it seems to me that we could add these multiple
    mcr> entries to certificates, using dummy algorithms, and test them in
    mcr> the field against
    mcr> existing browsers, web servers, IDS, firewalls, etc.

    >> fact won't be able to get BR-compliant certs)....

    mcr> No, it involves two sets of signatures.
    mcr> The traditional set and the new, yet-to-be-precisely-defined set.

    > Yes, but I had understood these tbe encoded on the wire as if they
    > were a new signature algorithm, with the result that such a
    > certificate would not be verifiable by an existing client.

    > Perhaps we should resolve this question first.

I believe that one proposal was to define a new signature type:
  RSA   -> F { RSA, PQ }
  ECDSA -> G { ECDSA, PQ }

and then, as you say, that would not interoperate at all.

But, I think that another proposal is to introduce the additional signatures
and related book-keeping as extensions, without disrupting the current
signature mechanisms.

---

From: "Markku-Juhani O. Saarinen" <[email-masked]>
Date: Sun, 19 Jan 2020 19:22:29 +0000

> and related book-keeping as extensions, without disrupting the current

Hi,

As was noted when this draft was introduced, that PQ-in-extension mechanism
is patented and Isara has indicated to IETF that will not allow it to be
used royalty-free. See their IPR  disclosure:
https://datatracker.ietf.org/ipr/3287/   That tech is out there marketplace
and will probably remain proprietary -- see e.g. DigiCert (
https://docs.digicert.com/certificate-tools/post-quantum-cryptography/pqc-toolkit-setup-guide/
 ).

The theory was discussed in "Transitioning to a Quantum-Resistant Public
Key Infrastructure" ( PQCrypto 2017, https://eprint.iacr.org/2017/460.pdf )
which is related to the OQS implementation that works with OpenSSL and TLS
( https://github.com/open-quantum-safe/openssl/tree/OQS-OpenSSL_1_1_1-stable
 ).

There's also a separate Java implementation documented in "X.509-Compliant
Hybrid Certificates for the Post-Quantum Transition" (
https://www.theoj.org/joss-papers/joss.01606/10.21105.joss.01606.pdf  ).
However the Isara-supported qTesla algorithm discussed in that report has
had some problems and I'm not sure of its current status (
https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/round-2/official-comments/qTESLA-round2-official-comment.pdf
).
Their customers are happy if they had a hybrid fall-back because it was
already being shipped out.

The OQS implementation seems to currently treat hybrid keys and signatures
simply as OCTET STRING blobs and assigns an arbitrary OID for each such
pair; I got 1.3.9999.2.2 for a  p256_dilithium2 cert I just created. They
emphasize that this is research code and not for production; the OID is of
course not valid and the key/signature format is not properly documented as
far as I know.

This kind of solution would require n*m OIDs -- perhaps this is manageable,
perhaps not -- the number of ciphersuites we used to have in TLS is an
indication that things may get out of hand, especially if we further
consider different hash functions used for signatures. Anyway, the
additional ASN.1 structure bytes introduced by the draft would essentially
document the structure of such blobs and put them under a single and/or a
small number of OIDs. (Correct me if I'm wrong.)

It would seem that the question of hash functions used in conjunction with
the signature algorithms, and how to identify those, needs to be figured
out. It may be reasonable to use SHA3 also in conjunction with the
classical RSA/ECC sigs here ?

Ultimaco also has a commercial toolkit (
https://hsm.utimaco.com/solutions/applications/post-quantum-crypto-agility/ )
but I'm not 100% which one they're using. It probably interoperates with
the OQS kit at some level since they've worked with Microsoft to get Picnic
(Microsoft's PQ signature proposal) to work with it. This in turn is used
e.g. with Microsoft's PQ VPN ( for details of cert generation, see
https://github.com/microsoft/PQCrypto-VPN/blob/master/openvpn/config/picnic-pki.md
 ).

Sorry if I left someone out. There have been PQ X.509 trials at least for 5
years (strongSwan had Bliss in 2015 --
https://wiki.strongswan.org/projects/strongswan/wiki/Bliss ) but no effort
on serious interop as I am aware.

Cheers,
- markku

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 20 Jan 2020 05:12:04 -0800

On Sun, Jan 19, 2020 at 11:22 AM Markku-Juhani O. Saarinen <
[email-masked]> wrote:

> wrote: hybrid fall-back because it was already being shipped out.
>

> This kind of solution would require n*m OIDs -- perhaps this is
> manageable, perhaps not -- the number of ciphersuites we used to have in
> TLS is an indication that things may get out of hand, especially if we
> further consider different hash functions used for signatures. Anyway, the

It's not clear to me that this level of complexity is required. At least on
the Web, each algorithm would need to be individually considered by CABF
and the browser vendors, so having a lot of flexibility here isn't that
much of an asset, and having multiple tiers of parameters is not great. So,
absent some evidence that we need this level of flexibility, I tend to
think the one-oid-per-combo approach is fine.

It might still be worth having an RFC which defined how to mint new oids,
but that need not have complex on-the-wire internal structure.

-Ekr

---

From: "Markku-Juhani O. Saarinen" <[email-masked]>
Date: Mon, 20 Jan 2020 14:40:15 +0000

On Mon, Jan 20, 2020 at 1:12 PM Eric Rescorla <[email-masked]> wrote:

> It's not clear to me that this level of complexity is required. At least
> on the Web, each algorithm would need to be individually considered by CABF

Hi,

I'd be fine with either way (on the hardware firmware front) and colleagues
working on the TLS code comment that they don't see much difference in
implementation complexity either. The additional structure is certainly
helpful in the experimentation phase and is there to make things easier and
more robust, not harder. We would just like to have at least one open
specification for this thing, and preferably not more than one.

Basically the only additional structure carried here is the OIDs for the
key and signature components. Their lengths need to be encoded anyway, so
some structure is needed.

The PQC binary formats don't define what kind of keys/signatures they are
or how long they are. So I see the advantage of having that information
available at least somewhere. Combining several OIDS directly into a single
OID, or having to go through IANA to get a one or two dozen new OIDs for
each variant or hash function combination seems clumsy.

A couple of additional technical points:
- The reason why I mentioned SHA3/SHAKE for RSA and ECC is that this would
seem to allow message hashing to be performed only once, rather than twice
(at least for Dilithium and Falcon).
 - We don't see this as being as widely used for TLS server authentication
as for smart cards, secure elements and similar applications that can't
just switch or negotiate certificate chains on the fly. I work on the
hardware side myself and especially there we have additional considerations
such as hardcoded cert chains and FIPS certification, which is currently
only available for the hybrid case. I wouldn't want to leave the issuance
of OIDs for this purpose at the mercy of TLS folks, which is just one of
many applications of this format.

Cheers,
- markku

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 23 Jan 2020 15:21:51 -0800

> many applications of this format.

Isn't that the point of OIDs, though, that no one is at the mercy of anyone
else, and can just mint their own OIDs as needed?

-Ben