Section 8.1: Crypto-agility in certificate hash verification

[aboba]

Currently, Section 8.1 only considers support for the SHA-256 hash. algorithm:

"If algorithm of fpr is equal to "sha-256", and value of fpr is equal to ref_fpr, the certificate is valid. Return true."

While SHA-256 is the default hash algorithm specified in RFC 8122, it's possible that in the future other algorithms may be supported or even preferred.

So I'd suggest that fingerprints with an algorithm value of 'SHA-256' be considered, along with fingerprints with algorithms that are both supported and stronger than 'SHA-256'. The fingerprint is then calculated on the certificate using the supported algorithms and matched.

From RFC 8122 Section 5.1:

"An endpoint MUST select the set of fingerprints that use its most
preferred hash function (out of those offered by the peer) and verify
that each certificate used matches one fingerprint out of that set.
If a certificate does not match any such fingerprint, the endpoint
MUST NOT establish the TLS connection."

[martinthomson]

So the reference identity is provided as a set of hashes, keyed by a hash algorithm identifier? That would be consistent with RFC 8122.

We then need to decide whether all have to match or just one (assuming that one is acceptable to the browser). That is, if we have two good hashes that are both supported and one is wrong, is that an error that the browser needs to recognize?