Re: [lamps] Hybrid pkix isn't needed

[Michael Markowitz <[e-mail]>]

Consider the following scenario:



During enrollment a user obtains a signing cert A. They use A to reauthenticate to their CA and obtain an RSA cert (R1), and then a Kyber cert (K1). Sometime later the same user leverages A to obtain another RSA cert (R2) and another Kyber cert (K2), say with different attributes, from the same CA. Maybe many more RSA and Kyber certs are issued to that user.



Now imagine that -- according to a security policy specified by the CA -- the pair [R1,K1] must be used for certain purposes  in some protocol P involving a hybrid KDF, while R2, K2, etc. are only to be used for other purposes (maybe separately).



What's the easiest way to ensure that a relying application when presented with R1, finds K1 rather than K2 as the other input into P? Sure this could be done in proprietary ways, but an innocuous (non-critical) extension linking the paired keys has a certain elegance. Also note that the user, to participate in P's hybrid KDF, doesn't need to do anything different from what they're already doing classically: they simply present the appropriate RSA cert, R1. It's only the relying (server?) app that must be modified to find K1 and carry out P. Kinda' useful in an enterprise environment in which end-entity certs are easy to update, but existing PKI clients are hard (i.e., expensive) to update -- or to even find!



To your points: a non-critical extension is "optional" -- no one will be forced to do anything with it. And I have trouble imagining another "transition model" that helps a relying server app find K1 rather than K2 without: new info provided by the client, a proprietary repository hack that links paired certs, or worse yet (heaven forbid!), abominable hybrid certs.



-mjm





-----Original Message-----
From: Spasm <[e-mail]> On Behalf Of Watson Ladd
Sent: Sunday, January 29, 2023 3:43 PM
To: [e-mail]
Subject: [lamps] Hybrid pkix isn't needed



Dear all,



I don't think linking certs or special provisions for hybrid encryption or authentication are a good idea.  A hybrid encryption scheme should be an encryption scheme with a public and private key, just like any other key you can put in the PKIX.



If for backwards compatibility you want to have multiple kinds of keys just like we do with RSA and ECDSA keys in TLS, just do that! Don't add complexities to try to link them or force people to find both keys at once for an operation. We know that the transition model with multiple unrelated certs works, and we have experience and fixed bugs that resulted. Let's use that instead of have new bugs to fix.



The other thing is hybrid auth is worthless. Authentication breaks are not retroactive: a break of an algorithm at a time in the future doesn't threaten the security properties of authentication in the past. That's different from encryption, where you do potentially want to ensure a new post-quantum algorithm is no worse than a classical one, but the case for it is fairly weak.



Sincerely,

Watson Ladd