Re: [Secdispatch] Problem statement for post-quantum multi-algorithm PKI

["Martin Thomson" <[e-mail]>]

I'll add that while it is clear that there are some hard research-y pieces to this (like finding decent primitives), much of the work we might decide to do is straight-up engineering.  The work that Douglass has done for TLS is a great example of that.  We might not have reached conclusions on some of the finer points, but thanks to the work already done, we're down to making what are fundamentally just engineering decisions.  Here I say "just" advisedly, because have well-established processes for resolving any disagreements of that nature.

On Wed, Sep 18, 2019, at 02:14, Richard Barnes wrote:
> +1 on the last point here -- we should get started on PQ stuff now 
> (including transition strategies), and should not waste time on 
> unrelated things, like replacing X.509.
> 
> --Richard
> 
> On Tue, Sep 17, 2019 at 10:10 AM Douglas Stebila <[e-mail]> wrote:
> > I'm a little late to the discussion, and new to the secdispatch mailing list, but hopefully not too late. I think this is an important problem to address, and sooner rather than later. NIST is still a few years away from having an outcome, but we can start laying the framework for how we'll use the resulting algorithms. Although not everyone is convinced by "hybrid" / "multi-algorithm", there seems to be sufficient interest for it (e.g., the panel discussion at the NIST PQC standardization conference last month), that it's worth investing the time to investigate further. I'm involved in a draft about hybrid key exchange in TLS for which there is no clear path, but lots of opinions and discussion worth having. I'm also involved in an open source project (openquantumsafe.org) where we are already wanting to prototype hybrid authentication in protocols relying on X.509, and we'd be happy to coordinate with others wanting to do so. It would be really unfortunate if deployment of quantum-resistant algorithms was delayed even further because we spend 3-5 years struggling with network protocols and standards *after* NIST picks some algorithms, when we could have started that aspect earlier.
> > 
> > Douglas
> > 
> > 
> > On Wed, 11 September 2019, Mike Ounsworth <[e-mail]> wrote:
> > 
> >> Hi SecDispatch,
> >> This got bounced here from LAMPS because the scope is potentially more than a "limited" pkix change, and because this needs multi-WG visibility to decide on a category of solution.
> >> 
> >> 
> >> Background / history
> >> --------------------
> >> The Post-Quantum community (for example, surrounding the NIST PQC competition), is pushing for "hybridized" crypto that combines RSA/ECC with new primitives in order to hedge our bets against both quantum adversaries, and also algorithmic / mathematical breaks of the new primitives.
> >> 
> >> A year and a half ago, a draft was put to LAMPS for putting PQ public key and signatures into X.509v3 extensions. This draft has been allowed to expire, but is being pursued at the ITU.
> >> https://datatracker.ietf.org/doc/draft-truskovsky-lamps-pq-hybrid-x509/
> >> 
> >> Earlier this year, a new draft was put to LAMPS for defining "composite" public key and signature algorithms that, essentially, concatenate multiple crypto algorithms into a single key or signature octet string. This draft stalled in LAMPS over whether it is the correct overall approach.
> >> https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-sigs/
> >> 
> >> Now I'm taking a step back and submitting a draft that acts as a semi-formal problem statement, and an overview of the three main categories of solutions.
> >> https://datatracker.ietf.org/doc/draft-pq-pkix-problem-statement/
> >> 
> >> 
> >> 
> >> My Opinion
> >> ----------
> >> Personally, I'm fairly agnostic to the chosen solution, but feel that we need some kind of standard(s) around the post-quantum transition for certificates and PKI. Personally, I feel that Composite is mature enough as an idea to standardize as a tool in our toolbox for contexts where it makes sense, even if a different mechanism is preferred for TLS and IPSEC/IKE.
> >> 
> >> 
> >> 
> >> Requested action from SECDISPATCH
> >> ---------------------------------
> >> 1. Feedback on the problem statement draft. https://datatracker.ietf.org/doc/draft-pq-pkix-problem-statement/
> >> 2. Discussion of how to progress this.
> >> 
> >> 
> >> 
> >> PS I'm a new IETF'er, please be gentle :P
> >> Thanks,
> >> - - -
> >> Mike Ounsworth | Software Security Architect
> >> Entrust Datacard
> >  _______________________________________________
> >  Secdispatch mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/secdispatch
> _______________________________________________
> Secdispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdispatch
>