tree 27d6f28485ec0c04bb9eda798e2ebbc7464882dc
parent 9f376b0694dfb8528fa2200369b48632563e972f
author David Benjamin <davidben@google.com> 1708717030 -0500
committer Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> 1709661804 +0000

Fix delegated credential signature algorithm handling

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>