Subject: [lamps] Call for Presentations at the LAMPS Interim Meeting on 28 Jan 2021

From: Russ Housley <[email-masked]>
Date: Sat, 9 Jan 2021 13:51:37 -0500

I gave this presentation at the NIST NCCoE Virtual Workshop on Considerations in Migrating to Post-Quantum Cryptographic Algorithms: https://www.nccoe.nist.gov/sites/default/files/10-Housley-NCCoE-Workshop-Transition-to-PQC-Certificates.pdf

This short presentation still captures my view.  Are there people with a different view that would like time on the agenda at the LAMPS Interim on 28 Jan?  I would like to make sure that all point of view are heard.

Russ

---

From: Mike Ounsworth <[email-masked]>
Date: Mon, 11 Jan 2021 23:33:02 +0000

Hi Russ,

Your slides refer to

Has known pitfalls of the "jumbo" certificate, which carried a key agreement public key and a signature public key for the same user" 

Was that from the 1997 PKIX mail list thread titled "Combo DSS/ElGamal keys" ? If so, the objections I'm seeing were mostly to do with mixing key usages -- ex.: nonrepudiation and key transport keys potentially having different key policies like validity period or private key escrow. Or the argument that revoking the keyex key due to, for example, bungling the backup copy would have the side-effect of invalidating any signatures produced by the signing key which would not have been part of the backup.

You may need to expand a bit on which arguments from that thread apply to Composite where all component keys must have the same keyusage and are intended to be used as an atomic object for producing composite signatures.

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Russ Housley
Sent: January 9, 2021 12:52 PM
To: LAMPS <[email-masked]>
Subject: [EXTERNAL][lamps] Call for Presentations at the LAMPS Interim Meeting on 28 Jan 2021

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

Russ

_______________________________________________
Spasm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spasm

---

From: Russ Housley <[email-masked]>
Date: Tue, 12 Jan 2021 17:49:28 -0500

Mike:

These were the Jumbo Certificates that were used in the early days of the UD Defense Message System development.  They were abandoned before production, and they included a DSS and KEA public keys.  IN that system, the DSS private key was not escrowed, but the KEA private key was escrowed.  The mis-match with the key usage extension was just one problem.

The DSS key and the KEA key had the same lifetime, so some of the concerns that you reference were avoided.

There were many issues with revocation.  Revoking the certificate made both the DSS key and the KEA key unusable, even in situations where one of them was still workable.

Russ

> On Jan 11, 2021, at 6:33 PM, Mike Ounsworth <Mike.Ounsworth=[email-masked]> wrote:
> 
> Hi Russ,
> 
> Your slides refer to
>

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 13 Jan 2021 03:29:02 +0000

Hi all,

I have been on both sides of the argument, Classical+PQ signatures or
parallel (classical, PQ). Recently I have been thinking that we probably
can't avoid keeping classical PKI for backwards compatibility which probably
makes the Classical+PQ sigs less appealing. Especially for live protocols
like TLS, this argument is even more relevant especially since the big cert
would be penalizing the classical peer with unnecessary PQ sig data. 

But I have heard some arguments for classical+PQ for non-TLS usecases. An
example could be SW Signing. I would argue that PKCS#7/CMS can include
multiple sigs (in SignerInfo) in the SignedData as clarified in RFC4853, so
even for SW Signing we may not need Composite or Hybrid Classical+PQ
Signatures. 

So, in summary, I am curious about the usecases where classical and PQ
signatures need to exist together. 

Thx,
Panos

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Russ Housley
Sent: Saturday, January 09, 2021 1:52 PM
To: LAMPS <[email-masked]>
Subject: [lamps] Call for Presentations at the LAMPS Interim Meeting on 28
Jan 2021

I gave this presentation at the NIST NCCoE Virtual Workshop on
Considerations in Migrating to Post-Quantum Cryptographic Algorithms:
https://www.nccoe.nist.gov/sites/default/files/10-Housley-NCCoE-Workshop-Tra
nsition-to-PQC-Certificates.pdf

This short presentation still captures my view.  Are there people with a
different view that would like time on the agenda at the LAMPS Interim on 28
Jan?  I would like to make sure that all point of view are heard.

Russ

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Jan 2021 12:55:02 -0500

Panos Kampanakis \(pkampana\) <pkampana=[email-masked]> wrote:
    > makes the Classical+PQ sigs less appealing.

First, I think that we need better terms to explain the two options.
Russ has used "One Certificate" and "Two Certificate".

I think that in the "One Certificate" case, that the PQC and traditional
(He said "traditional", and Panos said "classical", btw) CA signers would sign
both BQC and traditional keys.  Right?

    > Especially for live protocols

It seems that for live protocols we can negotiate, and the server can send
only what is needed, so there are really no byte-size issues.

    > even for SW Signing we may not need Composite or Hybrid Classical+PQ

That seems to be the parallel case, isn't it?

I have a different concern to ask as well:
  Are hash-based signatures in the classical or PQC category?

    > Jan?  I would like to make sure that all point of view are heard.

Russ' preference is for "Two Certificate" case.
I think that it is equivalent to having RSA and ECDSA ecosystems alive, which
I think we have managed reasonably well.
So I don't think that I have a diverging view.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Jan 2021 12:59:00 -0500

> both BQC and traditional keys.  Right?

...
    >> Jan?  I would like to make sure that all point of view are heard.

It occurs to me that what I'd like is to have the two options clearly
explained in a document, and for the two methods to be given clear names,
and then for the IETF to express a preference for what direction we will go
for each relevant protocol (TLS, IKE, PGP, CMS, COSE, ...).
In this case, the document really would be a Request for *Comments*

(maybe this belongs in SAAG)

---

From: Mike Ounsworth <[email-masked]>
Date: Wed, 13 Jan 2021 19:04:28 +0000

At the risk of over-complicating everything, we see the One-Cert vs Two-Cert discussion as in some senses orthogonal to our composite keys and signatures draft (draft-ounsworth-pq-composite-sigs).

I think that shoehorning this into a "one-cert vs two-cert" discussion is missing some of the potential value of the Composite proposal.

In writing the composite draft, we were careful to not make it a certificates draft, and instead stick strictly to public key, private key, and signature OIDs and ASN.1 encodings. At present, we are just looking at composite key and signature formats so that there is an obvious and standardized way to meet the NIST call for putting dual signatures on <thing>; whatever <thing> is.

For example, someone way want to combine both approaches and have a Two-Cert ecosystem where one of the certs is Composite:

Cert1: {RSA}
Cert2: {RSA, PQ}

Another example of them being orthogonal is a case where you have separate certificates {RSA}, {PQ}, but for protocol simplicity you want to use the composite signature structure {RSA,PQ} on the wire.

Our draft (draft-ounsworth-pq-composite-sigs) is really trying to be orthogonal from the One-Cert vs Two-Cert question.

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Michael Richardson
Sent: January 13, 2021 11:55 AM
To: LAMPS <[email-masked]>
Subject: [EXTERNAL]Re: [lamps] Call for Presentations at the LAMPS Interim Meeting on 28 Jan 2021

I think that in the "One Certificate" case, that the PQC and traditional (He said "traditional", and Panos said "classical", btw) CA signers would sign both BQC and traditional keys.  Right?

    > would be penalizing the classical peer with unnecessary PQ sig data.

It seems that for live protocols we can negotiate, and the server can send only what is needed, so there are really no byte-size issues.

Russ' preference is for "Two Certificate" case.
I think that it is equivalent to having RSA and ECDSA ecosystems alive, which I think we have managed reasonably well.
So I don't think that I have a diverging view.

---

From: Mike Ounsworth <[email-masked]>
Date: Wed, 13 Jan 2021 20:01:21 +0000

Another note: I am aware that LAMPS is a bit of an odd place for a draft that does not actually update any PKIX standards, but this has bounced a few times between LAMPS and SecDispatch (see thread "[Secdispatch] Can Composite sigs move back to LAMPS?"). There seems to be support for advancing this draft, and LAMPS is as good a home as any.

Therefore, I submit that LAMPS should look at standardizing mechanisms to meet the NIST call of carrying dual signatures in PKIX-like protocols. I would submit draft-ounsworth-pq-composite-sigs as one such mechanism, but likely not the only one. I think things will need to carry two signatures and LAMPS is in the right place to standardize an encoding. I believe standardizing "dual signatures" in general is independent from whether it's appropriate to use them on X.509 certificates.

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Mike Ounsworth
Sent: January 13, 2021 1:04 PM
To: Michael Richardson <[email-masked]>; LAMPS <[email-masked]>
Subject: Re: [lamps] [EXTERNAL]Re: Call for Presentations at the LAMPS Interim Meeting on 28 Jan 2021

Cert1: {RSA}
Cert2: {RSA, PQ}

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Michael Richardson
Sent: January 13, 2021 11:55 AM
To: LAMPS <[email-masked]>
Subject: [EXTERNAL]Re: [lamps] Call for Presentations at the LAMPS Interim Meeting on 28 Jan 2021

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________
Spasm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spasm

---

From: Russ Housley <[email-masked]>
Date: Wed, 13 Jan 2021 17:29:38 -0500

Mike:

I do not see them as orthogonal.  If one uses the composite signature structure {RSA,PQ} on the wire, and the public keys are in separate certificates, I cannot see how the validation works out.  Maybe I am missing something.  Can you put together some sides for the Interim meeting on the 28th to explain more fully?

Russ

> On Jan 13, 2021, at 2:04 PM, Mike Ounsworth <Mike.Ounsworth=[email-masked]> wrote:
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Jan 2021 17:45:26 -0500

Mike Ounsworth <Mike.Ounsworth=[email-masked]> wrote:
    > Therefore, I submit that LAMPS should look at standardizing mechanisms
    > to meet the NIST call of carrying dual signatures in PKIX-like
    > protocols. I would submit draft-ounsworth-pq-composite-sigs as one such
    > mechanism, but likely not the only one. I think things will need to
    > carry two signatures and LAMPS is in the right place to standardize an
    > encoding. I believe standardizing "dual signatures" in general is
    > independent from whether it's appropriate to use them on X.509
    > certificates.

I agree that the technical details of how to do this for CMS and PKIX
certificates belongs in LAMPS.

---

From: Mike Ounsworth <[email-masked]>
Date: Wed, 13 Jan 2021 22:49:37 +0000

Hi Russ,

Yes, I'm happy to present on the 28th.

I want to make sure I've got the right list of topics that people are interested in knowing. So far it sounds like my presentation should be:

- The general suggestion that LAMPS re-charter to work on hybrid key exchange and dual signature mechanisms for CMS and PKIX protocols, ie fulfill NIST's call for such mechanisms.
- Overview of the composite keys and signatures draft.
- Use-cases for composite certificates.
- Use-cases for composite keys and / or signatures independently of certificates.

Are there other topics that I'm the right position to present on?

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Russ Housley
Sent: January 13, 2021 4:30 PM
To: Mike Ounsworth <[email-masked]>
Cc: LAMPS <[email-masked]>
Subject: Re: [lamps] [EXTERNAL]Re: Call for Presentations at the LAMPS Interim Meeting on 28 Jan 2021

Mike:

Russ

>> parallel (classical, PQ). Recently I have been thinking that we 
>> probably can't avoid keeping classical PKI for backwards 
>> compatibility which probably makes the Classical+PQ sigs less appealing.
> 
>> like TLS, this argument is even more relevant especially since the 
>> big cert would be penalizing the classical peer with unnecessary PQ sig data.
> 
>> But I have heard some arguments for classical+PQ for non-TLS 
>> usecases. An example could be SW Signing. I would argue that 
>> PKCS#7/CMS can include multiple sigs (in SignerInfo) in the 
>> SignedData as clarified in RFC4853, so even for SW Signing we may not 
>> need Composite or Hybrid Classical+PQ Signatures.
> 
>> This short presentation still captures my view.  Are there people 
>> with a different view that would like time on the agenda at the LAMPS 
>> Interim on 28 Jan?  I would like to make sure that all point of view are heard.
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 14 Jan 2021 14:20:42 +0200

On Wed, Jan 13, 2021 at 07:04:28PM +0000, Mike Ounsworth wrote:
> At the risk of over-complicating everything, we see the One-Cert vs
> Two-Cert discussion as in some senses orthogonal to our composite
> keys and signatures draft (draft-ounsworth-pq-composite-sigs).

I do not think these are orthogonal.

For "one-cert" to make sense, the composite certificates must be
compatible with legacy software due to very slow transition times
(at least before things turn into hot mess). The certificates from
draft-ounsworth-pq-composite-sigs are not compatible in this way,
hence only really make sense in context of two-cert system.

But depending on the protocol, it might make sense to:

1) Negotiate supported algorithms and send only the legacy or composite
   certificate.

This seems to be the only viable way for TLS 1.3, as:

a) TLS is formally capable of negotiating certificate signing
   algorithms (even if in reality this does not work all that well due
   to missing server end implementation).
b) TLS can only transmit one end-entity certificate. And in reality,
   transmitting multiple certificate chains at once might not actually
   work in interoperable way.

2) Send both at once. This is necressary for protocols that are not
   interactive.

3) Decide that the protocol is lost cause due to being insufficiently
   crypto-agile. I am sure there are at least a few of those around
   (besides TLS version 1.2, TLS 1.3 fixes those flaws).

As to very slow transition times, consider that SHA-1 to SHA-2
transition in WebPKI took about a decade. And I am not fully sure that
things will move quickly after turning out into hot mess, as IIRC MD5 to
SHA-1 transition took like 3 years after that point.

And making hybrid certificates compatible with legacy software needs
some very ugly hacks, and there might be IPR issues too.

-Ilari