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

[Stephen Farrell <[e-mail]>]

Hiya,

On 16/09/2019 22:35, Panos Kampanakis (pkampana) wrote:
>> That seems to beg the question again as to why x.509 is needed at
>> all as part of a PQ solution.
> 
> Because there is nothing else as widely adopted. 

There is nothing "adopted" for PQ PKI, neither widely nor
as a niche.

> You haven't
> articulated what would replace X.509 

Yep, I said that before. It's worth a leisurely discussion
as to what might be done.

> and how the world would migrate
> away from such a ubiquitous standard. 

I didn't say we ought migrate away from x.509, for classic
algorithm uses. Just as acme account handling doesn't use
x.509, something that may be needed for a PQ PKI does not
have to use x.509.

Cheers,
S.

> Composite classic+PQ X.509 may
> not be the way to go, but replacing X.509 altogether with something
> new is not a realistic goal imo.
> 
> 
> 
> 
> -----Original Message----- From: Secdispatch
> <[e-mail]> On Behalf Of Stephen Farrell Sent:
> Monday, September 16, 2019 4:59 PM To: [e-mail] Subject:
> Re: [Secdispatch] Problem statement for post-quantum multi-algorithm
> PKI
> 
> 
> Hiya,
> 
> Replying to various folks at once...
> 
> On 15/09/2019 15:29, Ira McDonald wrote:
>> Hi,
>> 
>> Thanks for the link to Kenny's talk.
>> 
>> Stephen - The hard problem for automotive vehicles is that, even if
>>  Quantum Computing never comes to pass, algorithms and various 
>> implementations go on having new weaknesses found over time. But
>> decent performance requires hardware assist, in many cases. But
>> automotive ECUs are very unlikely to start have large FPGAs added 
>> soon.  Replacing 100s of expensive ECUs in fielded vehicles to
>> allow practical algorithm agility is not going to happen.  This
>> issue that Michael Richardson mentioned is at the top of the list
>> for the automotive cybersecurity community.
> 
> I don't understand how devices that are not going to be updated can
> support algorithm agility. Perhaps you mean that you want to deploy
> those devices soon and not update for a couple of decades or
> something? If so, that sound like a bad plan to me, and one that'd be
> better to not cater to really. (RFC8240 has lots of discussion of
> that.)
> 
> 
> On 16/09/2019 17:05, Mike Ounsworth wrote:
>> My Goal: multi-vendor interop on PQ certificates.
> 
> That seems to beg the question again as to why x.509 is needed at all
> as part of a PQ solution.
> 
>> I'm coming from the perspective of a CA; it can take years to
>> distribute a root cert to all the places it needs to be before you
>> can really start using it. Plus, people want to playing with these
>> things ASAP to understand the scope of infrastructure changes
>> required. There's the time pressure.
>> 
>> I think you're right that to really deploy any meaningful 20 year
>> root using, for example the small lattice schemes, we'll need to
>> wait for the NIST PQC algs to stop having so much churn.
>> 
>> That said, laying the groundwork for the "hybrid" property in 
>> certificates that the NIST PQC community is calling for will
>> require much debate and a few RFCs. This work is necessary and
>> independent of the choice of algorithm from the NIST PQC
>> competition, so why should we wait until 2023 to _start_ thinking
>> about it? Why not do it in parallel, be able to offer alpha test
>> versions of PKI products before the conclusion of the NIST PQC, and
>> be ready to drop-in the NIST winners the day they're ready?
> 
> One reason to not do it in parallel is that we don't know how the
> winning algorithm parameters will look. I can easily imagine NIST
> modifying how those are encoded and/or introducing new variations,
> after basic algorithms have been picked, leading to things having to
> be re-done.
> 
> (Sorry if the quoting is messed up below, if so, it was messed up in
> my MUA before I started is my excuse:-) On 16/09/2019 19:06, Daniel
> Van Geest wrote:
>> Can we support multiple signatures inside a certificate? I don't
>> think so.
>> 
>> Why not?  Mike’s problem statement draft has two potential
>> technical solutions doing just that, each with advantages and
>> disadvantages. Or is there more of a logistical or other issue?
>> Knowing why you think we can’t support multiple signatures inside a
>> certificate could help refine the problem statement.
> 
> Again, that assumes that x.509 is a sensible part of a solution. We
> should first question that. (Mike's draft [1] doesn't.)
> 
> Secondly, even if x.509 additions were useful somehow for backwards
> compatibility (which I find hard to believe TBH) then dealing with
>> 1 certificate is likely far easier than messing about inside certs
> and thereby breaking all the lovely/horrible x.509 code out there. So
> Mike's section 2.1 [1] is way easier than the 2.[2|3] approaches,
> despite it being the one with no specific drafts.
> 
> Again, all that said, I do understand why it may be attractive for
> those who produce certificates to argue for putting the PQ magic
> beans inside x.509. There are costs elsewhere implied in doing that,
> so it ought not be a starting-out assumption.
> 
> I don't consider the question as to why a PQ x.509 is needed nor why
> now has been satisfactorily answered so far.
> 
> Cheers, S.
> 
> [1] https://tools.ietf.org/html/draft-pq-pkix-problem-statement 
> _______________________________________________ Secdispatch mailing
> list [e-mail] 
> https://www.ietf.org/mailman/listinfo/secdispatch
>