-
Notifications
You must be signed in to change notification settings - Fork 6.6k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Replace net::SignatureAlgorithm with an enum
With the disaster that is RSA-PSS constrained, we no longer need so complex of a SignatureAlgorithm representation. A simple enum suffices. I opted to not even include a sig/hash decomposition because that isn't universally applicable. E.g. Ed25519 is locked to one hash and I hope future schemes will be too. (Ed25519 also uses the hash in more complex ways than just a prehash.) And there's no fundamental reason why RSA-PSS has to use the same MGF-1 and message hashes, though it would be pointless to pull in two different ones. This means code which previously looked at the decomposition needs to be reworked. Rationale for the choices I made: - SimplePathBuilderDelegate needs to decide on allowed and forbidden signature algorithms. I replaced it with a giant switch/case. This code is destined to move with the library, so there are no forward-compat implications of listing out everything. The switch/case should also get shorter when we resolve https://crbug.com/1321688. I think this is also more sound because different signature algorithms may use their digests differently. It's better to evaluate the combination as a whole. - CertVerifyProc's ValidateHashAlgorithm rejects weak hashes from the OS and also detects SHA-1 algorithms. I did the above for similar rationale, except that the switch/case *does* have forward-compat implications. After https://crbug.com/1321688 is done, we may wish to reevaluate this, e.g. just detecting the two SHA-1 algorithms. In principle, that code is redundant with the underlying verifier's policies, but we find ourselves wanting to apply policy on top. As we move to the Chrome Root Store and our own verifier, that may be less important. - VerifySignedData converts a SignatureAlgorithm to OpenSSL's API, which often looks like decomposing it. I turned this into a switch/case. There are no forward compat implications as that'll move with the library. - GetTLSServerEndPointChannelBinding needs to compute the tls-server-end-point channel binding (RFC 5929, 4.1). This one is interesting because it is defined based on the sig/hash decomposition. "If the certificate's signatureAlgorithm uses a single hash function ..." and "if the certificate's signatureAlgorithm uses no hash functions or uses multiple hash functions, then this channel binding type's channel bindings are undefined at this time". This definition is a bit awkward. I've opted to just add an API to figure out the digest. In a better-defined scheme, we probably would have added a column to a hypothetical X.509 signature algorithms registry, effectively introducing a new property for the signature algorithm. This also avoids a switch/case outside the future library with no future path to trimming it down. - I just listed the two SHA-1 algorithms in HasSHA1Signature. That's only there to track some metrics anyway. Fixed: 1321691 Change-Id: I9b2cb57ae05821b98f98749f4e648d4dc79eadf9 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3770154 Reviewed-by: Matt Mueller <mattm@chromium.org> Commit-Queue: David Benjamin <davidben@chromium.org> Cr-Commit-Position: refs/heads/main@{#1028457}
- Loading branch information
Showing
22 changed files
with
470 additions
and
822 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.