We have cut a new -03 version of the Trust Anchor Identifiers draft:
URL:
https://www.ietf.org/archive/id/draft-beck-tls-trust-anchor-ids-03.txt
Status: https://datatracker.ietf.org/doc/draft-beck-tls-trust-anchor-ids/
HTML:
https://www.ietf.org/archive/id/draft-beck-tls-trust-anchor-ids-03.ht
On Monday, 16 December 2024 22:59:50 CET, Sean Turner wrote:
Ask:
Is the WG consensus to run four separate adoption calls for the
individual I-Ds in question?
I'm FOR adoption of all of the four mentioned drafts.
I don't have a strong opinion if they should be considered separately or
not.
>
> (C) within the PQ part, providing alternatives that are less likely
> to fail in the first place.`
>
I think there is some more to say about what would make a good alternative
KEM.
Let's consider Saber. There are differences between ML-KEM and Saber. A
simple implementation of Sab
> I think that if we pursue an alternative structured lattice KEM, it should
> bring at least another advantage to the table. From a performance
> perspective BAT ( https://eprint.iacr.org/2022/031 ) improves
> considerably over ML-KEM in certain use cases: its ciphertexts and public
> keys are sma
