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

[Mike Ounsworth <[e-mail]>]

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 <[e-mail]> On Behalf Of Mike Ounsworth
Sent: January 13, 2021 1:04 PM
To: Michael Richardson <[e-mail]>; LAMPS <[e-mail]>
Subject: Re: [lamps] [EXTERNAL]Re: Call for Presentations at the LAMPS Interim Meeting on 28 Jan 2021

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 <[e-mail]> On Behalf Of Michael Richardson
Sent: January 13, 2021 11:55 AM
To: LAMPS <[e-mail]>
Subject: [EXTERNAL]Re: [lamps] Call for Presentations at the LAMPS Interim Meeting on 28 Jan 2021


Panos Kampanakis \(pkampana\) <pkampana=[e-mail]> wrote:
    > 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.

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
    > like TLS, this argument is even more relevant especially since the big cert
    > 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.

    > 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.

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?

    > 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' 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 <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________
Spasm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/spasm