https://boringssl-review.googlesource.com/c/34884 tried to update to the newer DC draft, but didn't quite do so. In that update, DCs overcomplicated the signature algorithm negotiation so that there are two different signature algorithm lists, used in different contexts. The existing signature_algorithms extension is used to verify the signature *on* the DC, made by the end-entity certificate. On the server side, we should be using that to decide whether to use the DC, and we weren't. The new delegated_credentials extension contains another sigalg list. That is used to verify the signature *by* the DC, in the CertificateVerify message. (This means DC changes the operative sigalg list for the CertificateVerify message, which is quite a mess.) On the server side, the above CL mixed things up. When deciding whether to use DCs, it checked the correct list. When actually using DCs, it checked the wrong one. As a result, any time the DC list wasn't a subset of the main list, the connection would just break! Fix both of these, in preparation for redoing DCs over the upcoming SSL_CREDENTIAL mechanism. Thankfully we don't support one direction of DC usage (authenticating in C++ and verifying in Go), so there are fewer places to worry about mixing this up. Given this overcomplication, I'm now much, much less inclined to ever support DCs as a client, without an rfc9345bis to redo this. Bug: 249 Change-Id: Id5257e89a6c8daf1635757be473c45029492d420 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66550 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>fips-20240407
parent
9f376b0694
commit
efad2bfc83
8 changed files with 119 additions and 50 deletions
Loading…
Reference in new issue