On Wed, Oct 29, 2025 at 12:10:59PM -0400, David Benjamin wrote:
> The rules in RFC 5929 are quite unfortunate because it means that the
> application needs to actually recognize the signature algorithm, [...]
+1. I think we wanted the TSEP CB data to be "small". That was
misguided.
Though it need not be the application so much as the TLS implementation,
which can provide an accessor for getting at the CB data for any
supported CB type for a given connection.
> If I had a time machine, I would say the right answer would be that
> tls-server-end-point is completely disconnected from the certificate
> signature algorithm and instead is either a fixed hash (SHA-256 is fine),
> or determined from the TLS connection state, not the certificate. I don't
> have a time machine, but that might suggest updating the RFC to say:
Or just the identity function.
> 1. If the certificate signature algorithm is {one of these legacy entries},
> use {the hash algorithm that the old spelling provide}
> 2. Otherwise, it is SHA-256[*] and we move on with life
>
> [*] Or the cipher suite PRF hash if you like, but the channel binding
> already has a hardcoded SHA-256 dependency. If SHA-256 ever falls, defining
> a new channel binding will be the least of our headaches.
But it would be one of many headaches.
Nico
--
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
