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

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=40entrust.com@dmarc.ietf.org> 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 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 <spasm-bounces@ietf.org> On Behalf Of Michael Richardson
> Sent: January 13, 2021 11:55 AM
> To: LAMPS <spasm@ietf.org>
> Subject: [EXTERNAL]Re: [lamps] Call for Presentations at the LAMPS Interim Meeting on 28 Jan 2021
> 
> 
> Panos Kampanakis \(pkampana\) <pkampana=40cisco.com@dmarc.ietf.org> 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 <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm