tree 6f1da6c83a58808c568f31779fe6329b359ae0ca
parent 9e96cc5383e12853cd24cf3442fa691191b2bbf5
author David Benjamin <davidben@google.com> 1756853363 -0400
committer Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> 1756962245 -0700

Add X509_parse_with_algorithms

This controls the algorithms that the SPKI will be parsed with. Note
there is a decision point here with our API: is an X509 a holder of an
EVP_PKEY, and thus parsed with algorithms in mind, or is it just an
abstractly parsed certificate, and algorithms are instead passed to an
X509_get_publickey_with_algorithms.

This CL takes the first route, largely because upstream already went
down this path in many ways:

- X509_get0_pubkey expose the fact that X509's retain a cached EVP_PKEY.

- Upstream OpenSSL added X509_new_ex which passes an OSSL_LIB_CTX into
  the X509. It's a little unfortunate that this pattern relies on object
  reuse in d2i_X509, but so it goes.

- A caller using the same X509 to verify mutiple signatures (e.g. a root
  CA) might wish to hold on to the EVP_PKEY to avoid importing the key a
  bunch. (This probably doesn't matter too much, but if we ever add an
  API to precompute a table to speed up ECDSA verify...)

This changes follows in those footsteps. Note this means that the same
certificate bytes might produce semantically different X509 objects
(with or without the SPKI in EVP_PKEY form) depending on how it was
parsed. This is a little unfortunate but probably the most
straightforward model given where we are.

Bug: 42290364, 384818542
Change-Id: I8c0c95cb1d3221fc0b79a7749833c4f0d87646eb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/81787
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>