The rules in RFC 5929 are quite unfortunate because it means that the
application needs to actually recognize the signature algorithm, in
addition to breaking through the abstraction and decomposing it. It's
similarly ill-defined for RSA-PSS, which uses a couple different hash
functions, and need not match. This is particularly silly because the side
presenting the certificate does not actually need to evaluate the
certificate signature, and could be broadly opaque to it.
(signature_algorithms_cert aside, but dispatching on that is not very
common.)
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:
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.
On Wed, Oct 29, 2025 at 12:06 PM Nico Williams <[email protected]>
wrote:
> On Wed, Oct 29, 2025 at 03:54:11PM +0000, Kampanakis, Panos wrote:
> > Good idea. Option (f) could be an erratum that calls out EdDSA and
> > ML-DSA as examples of "built-in digest signatures" in X.509 that fall
> > under the non MD-5/SHA-1 hash bullet of RFC 5929.
>
> Is that truly an erratum? I think an update is in order. (Who shall do
> that work?)
>
> _______________________________________________
> TLS mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
