tree 8d79e18ffde2be2b6db41705a9a2cf4b6d063e7a
parent 336efd412e4533ab3461e0cd9cc193c964f59388
author David Benjamin <davidben@google.com> 1756584128 -0400
committer Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> 1757980144 -0700

Rewrite the X509_NAME parser

The old parser was a mess. It has to deal with X509_NAME using a
slightly different in-memory represtation than tasn_dec expects, and it
has to populate cached fields. On top of that, the handling of the cache
was not thread-safe.

It previously worked by first using the tasn_dec machinery to parse a
STACK_OF(STACK_OF(X509_NAME_ENTRY)), and then flattening it. Then it
makes a *new* STACK_OF(STACK_OF(X509_NAME_ENTRY)) with canonicalized
fields. Then it re-encodes that with tasn_enc to save the canonicalized
form.

Instead of all that, parse with CBS so we don't need an allocated
intermediate representation. We can just write it out into the
X509_NAME representation as we parse it.

For the two cached fields, fix the thread-safety issue by wrapping it in
a struct and managing it with an atomic pointer. I had vaguely hoped we
could avoid this, but that seems too complicated with the API we've got.
When computing the cached encodings, rather than making a new allocated
intermediate representation, we can just write a canonicalized encoder
and write it straight into a single CBB, so we only have one growable
array's worth of buffer.

It's faster too!

Before:
Did 1319499 Parse X.509 certificate operations in 5001015us (263846.2 ops/sec)
After:
Did 1794529 Parse X.509 certificate operations in 5000632us (358860.4 ops/sec)

Subsequent CLs will make the API const-correct, test threading, and
embed the X509_NAMEs into the X509 struct.

One nuisance: it's hard for an infallible x509_name_init to initialize
a STACK_OF(X509_NAME_ENTRY). For now I just made the zero state legal
and the add function materializes the STACK_OF on demand. We don't
expose the underlying object, so it doesn't matter much. Really we
should stop believing in fallible mallocs.

Bug: 42290417, 42290269
Change-Id: I0081c75dc06c76c3863eb9418e61262953c9179f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/81891
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>