That was very insightful. A few clarification questions inline:
On 04.02.26 16:04, Eric Rescorla wrote:
Not sure what "it" refers to. Assuming the proposed /pq_cert_available/ extension, isn't it typically the case that client authentication requires support of the higher layers (and not done exclusively at TLS layer)? So I don't see this as benefit, since this might mean you need to change /both/ TLS stack as well as higher layers.2. It allows you to handle the client authentication case as well
Is the commitment per connection or per client? Could you explain how does one infer that?Once the server has committed to algorithm X it needs to maintain algorithm X for the validity period, even if it also supports algorithm Y.
[...] I haven't worked through this entirely, but I think the correct semantics need some fairly close study to avoid creating situations where one side or another is bricked.
I believe formal analysis can help here.
the client (usually) knows the server's identity in advance [...]
I agree with your overall point on asymmetry but I wonder why do you write "(usually)"? If the client doesn't know the server's identity, what does it ask for in the connection? In other words, what are the real-world use cases when client doesn't know the server's identity in advance? Are there any such specs?
-Usama
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
