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, 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.)
I strongly support the position that it is a bad idea to require
implementations to know the internals of what should be black box
constructions.
> 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:
And this, in full knowledge of Australia Signals Directorate's decision
to proscribe[1] SHA2-256 after 2030 (this reduces my confidence in the
ASD's ability to make sound judgements, not the security of SHA256,
its "susceptibility" to Grover's algorithm is far too remote to warrant
action or even concern).
--
Viktor.
[1]
https://www.cyber.gov.au/business-government/asds-cyber-security-frameworks/ism/cybersecurity-guidelines/guidelines-for-cryptography
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
