Re: [lamps] Hybrid pkix isn't needed

Think there are two kinds of fail mode hybrid cert try to guard against: 
Quantum computer came out breaking classical asymmetrical crypto, or PQ 
algorithm we chooses was not that great and it broken down by new 
classical attack

2023-01-31 오전 3:49에 Watson Ladd 이(가) 쓴 글:
> On Mon, Jan 30, 2023 at 10:30 AM Mike Ounsworth
> <Mike.Ounsworth@entrust.com> 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.
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm