Re: [lamps] Hybrid pkix isn't needed

[Watson Ladd <[e-mail]>]

On Sun, Jan 29, 2023 at 4:59 PM Michael Markowitz
<[e-mail]> wrote:
>
> 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).

Why would we want to do this? My contention is that we don't actually
want to do this: the right approach to hybrids is to make a RK-cert
containing both an RSA key and Kyber key. In part that's to avoid the
issue when the extension doesn't work and analysis of protocols
doesn't include it (although they likely will be robust to it).

>
>
>
> 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!

I'm a little confused by the terminology here so I'm not sure I
understand this scenario well enough to respond.
>
>
>
> 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.

How is it that ECDSA certs got rolled out without such a mechanism?
The answer of course is that relying parties signaled their
capabilities and the applications sending end entity certs sent the
chain that used the preferred algorithm. Maybe I'm missing some real
constraint here, but that seems like the right way forward to me.

>
>
>
> -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



-- 
Astra mortemque praestare gradatim