Re: [lamps] Current efforts in the direction of draft-truskovsky-lamps-pq-hybrid-x509?

[Tim Hollebeek <[e-mail]>]

DigiCert was very supportive of this approach in the past, but it has a bunch of
downsides that were discovered upon closer examination.  The IPR situation
also did not help.

The problem is that interoperating with existing systems doesn’t actually buy
you much, as you still pay the cost for transporting the large PQC keys.  That
means you pay a pretty high price early in the transition for only marginal
benefits in use cases where certificate size matters.

You can't effectively cache the PQC keys because that leaks information about
whether the site has been visited before, and it's difficult to use it in a mode
where you operate with both existing and new systems, because the requirement
to support existing systems makes downgrade attacks against the new systems
feasible.  You then need some policy mechanism to communicate which
systems need to be checking both keys/signatures, and which are allowed
to use just the default key, and all that infrastructure is about as complicated
as the infrastructure to manage two certs via policy or negotiation and just
use the appropriate single key cert.

Using two single key certificates does have its own certificate management
challenges, and those have recently started being discussed and explored.
But managing multiple keys via multiple certificates does seem to be more
straightforward, and does seem to be the consensus direction at this time.
Using chameleon certs is a clever idea that allows a single certificate to be
managed, but allows each component of the pair to be used individually.
But it's still a very, very new trick and could use more careful analysis.

Most of the recent work has focused on composite keys instead, where the
two keys are put together into a single key, which requires support for a new
"algorithm", but requires far fewer changes throughout the rest of certificate
management and tooling.  This provides most of the benefits hybrid was 
intended to provide (falling back to RSA instead of plaintext if the PQC 
algorithm fails), but in a form factor that's much more compatible with
existing software.

There's been some talk of refreshing / updating the hybrid draft, but 
nothing has come of it so far.  A lot of this is very much still a work in 
progress, and people are still figuring things out, so be prepared for things to 
change as the working group continues to try to figure out these important 
questions.

-Tim

> -----Original Message-----
> From: Spasm <[e-mail]> On Behalf Of Iyán Méndez Veiga
> Sent: Friday, July 7, 2023 10:05 AM
> To: [e-mail]
> Subject: [lamps] Current efforts in the direction of draft-truskovsky-lamps-pq-
> hybrid-x509?
> 
> Hello,
> 
> I recently found the interesting draft-truskovsky-lamps-pq-hybrid-x509, which
> I think it would allow a much smoother PQC transition.
> 
> Unfortunately, the draft has expired some time ago, and I couldn't find any
> derivative work apart from a small reference by Mike that this was
> standardized by ITU-T [1]. I guess he was referring to section 7.2.2 of their
> X.509 (10/2019):
> 
> https://www.itu.int/rec/T-REC-X.509-201910-I
> 
> There was also some recent mention to the draft in the IETF 116 Hackathon
> "PQ Use in the Read world: X.509 Keys, signatures, certificates and protocols",
> but I couldn't find any details.
> 
> It was also pointed out to me [2] that this approach was protected by a patent
> owned by ISARA, but later it seems they relaxed this restriction [3].
> 
> DigiCert seems to be testing this idea as well [4].
> 
> Could anyone summarize to me the current status of this work? Why this draft
> never got updated? Are there any plans to continue working on this with an
> active draft?
> 
> People from the Open Quantum Safe project have shown interest in
> implementing this, since it's a good approach with a straightforward
> backwards compatibility, but since changes have to be made to OpenSSL as
> well, and I quote here "not having this at least in active Draft state at IETF
> makes this a non-starter".
> 
> Looking forward to learning more about the status of this work.
> 
> Best regards,
> Iyán
> 
> [1]: https://mailarchive.ietf.org/arch/msg/spasm/VJPJXLquDjEjEmRysiGrdsL-
> Nwc/
> [2]: https://github.com/open-quantum-safe/oqs-provider/discussions/209
> [3]: https://www.helpnetsecurity.com/2022/10/26/isara-digital-certificate-
> patents-quantum-security/
> [4]: https://docs.digicert.com/en/certcentral/certificate-tools/post-quantum-
> cryptography.html#idm45907393047856
> 
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm