tree 1082eb8907e5988aec6c69970e1dd9349bd76269
parent a317d59c79cf4f72d30f24ba2eaeb0a7523caf4a
author David Benjamin <davidben@google.com> 1756494985 -0400
committer Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> 1756962162 -0700

Rewrite X509's parser with CBS/CBB

In doing so, embed a whole host of types into X509. With all this, we
can *finally* add extra parameters to the parser, like lists of
supported algorithms or flag-protecting future changes. In the previous
state, it went through a very messy reflection-based framework.

Since we now control the parser entrypoint, this also means we can
handle the cached encoding differently. Just to make the
X509_parse_from_buffer and d2i_X509 flows more uniform, we now always
save a CRYPTO_BUFFER containing the whole certificate, and then
TBSCertificate marshalling finds the TBSCertificate from there. (Though
it is still possible to create X509 objects without CRYPTO_BUFFERs.)

That in turn means the generic ASN1_ENCODING path doesn't need to store
a CRYPTO_BUFFER anymore, so all that is now unwound. If we rewrite the
CSR and CRL parsers, then ASN1_ENCODING can be removed entirely.

As a bonus, this new parser is significantly faster!
Before:
Did 1037634 Parse X.509 certificate operations in 5000690us (207498.2 ops/sec)
After:
Did 1318068 Parse X.509 certificate operations in 5000462us (263589.2 ops/sec)

(The X509_NAME parser is still using tasn_dec, so there's still some
overhead there. This also does not remove the overhead from X509's
in-memory representation where lots of parts of the certificate get
copied separate allocations.)

Update-Note: This CL is not expected to change the external behavior of
the X.509 parser, but it's a lot of code that had to get shuffled
around, so if something funny happens around X.509, this is a likely
culprit.

Bug: 42290417
Change-Id: Ia4142f5e8d31b041176a545379c7df30e946a670
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/81781
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>