Re: [lamps] Hybrid pkix isn't needed

[Mike Ounsworth <[e-mail]>]

Watson Ladd said:

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

Since you're comparing this with encryption, I'm taking "authentication" here to mean "signature primitives".

For TLS or IKEv2, yes, signatures are less urgent than encryption, but in general you know that you're fighting a losing battle here, right? Especially since the NSA in their CNSA 2.0 have marked code-signing as the most urgent use case to migrate to PQC. The idea is that a device will leave your manufacturing facility with a burned-in trust anchor that it should use for validating future firmware patches. For good reason you can't change trust anchors in the field, so we need to make sure those algorithms are going to stand the test of time for the lifetime of the device.

Another example is PDF signing; if I can factor the signer's private key so I can modify and re-sign the PDF then what's stopping me from also back-dating the timestamps?

Yet another is S/MIME email certificates: you need PQ CAs before you can issue PQ encryption certs.

---
Mike Ounsworth

From: Spasm <[e-mail]> On Behalf Of Michael Markowitz
Sent: Sunday, January 29, 2023 6:59 PM
To: Watson Ladd <[e-mail]>; [e-mail]
Subject: [EXTERNAL] Re: [lamps] Hybrid pkix isn't needed

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________

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]<mailto:[e-mail]>> On Behalf Of Watson Ladd
Sent: Sunday, January 29, 2023 3:43 PM
To: [e-mail]<mailto:[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

Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.