Re: [lamps] Hybrid pkix isn't needed

[Watson Ladd <[e-mail]>]

On Mon, Jan 30, 2023 at 10:30 AM Mike Ounsworth
<[e-mail]> wrote:
<snip>

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

In that case what's the point of hybridization: you need very high
security due to lack of updates, you're not signing very much, so XMSS
or another hashed based scheme is the obvious choice. Just issue those
certs, rather than add complex behavior to find some other cert in the
chain to actually use. Although I do wonder what happens when the key
you use leaks.

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

Why? There's nothing wrong with mixed algorithms in a chain. The
bigger issue here is root program policies about what can be signed.