See also 006906cddda37e24a66443199444ef4476697477 from OpenSSL, though
this CL uses a different strategy from upstream. Upstream makes
ASN1_item_ex_i2d continue to allow optionals and checks afterwards at
every non-optional call site. This CL pushes down an optional parameter
and says functions cannot omit items unless explicitly allowed.
I think this is a better default, though it is a larger change. Fields
are only optional when they come from an ASN1_TEMPLATE with the OPTIONAL
flag. Upstream's strategy misses top-level calls.
This CL additionally adds checks for optional ASN1_TEMPLATEs in contexts
where it doesn't make sense. Only fields of SEQUENCEs and SETs may be
OPTIONAL, but the ASN1_ITEM/ASN1_TEMPLATE split doesn't quite match
ASN.1 itself. ASN1_TEMPLATE is additionally responsible for
explicit/implicit tagging, and SEQUENCE/SET OF. That means CHOICE arms
and the occasional top-level type (ASN1_ITEM_TEMPLATE) use ASN1_TEMPLATE
but will get confused if marked optional.
As part of this, i2d_FOO(NULL) now returns -1 rather than "successfully"
writing 0 bytes. If we want to allow NULL at the top-level, that's not
too hard to arrange, but our CBB-based i2d functions do not.
Update-Note: Structures with missing mandatory fields can no longer be
encoded. Note that, apart from the cases already handled by preceding
CLs, tasn_new.c will fill in non-NULL empty objects everywhere. The main
downstream impact I've seen of this particular change is in combination
with other bugs. Consider a caller that does:
GENERAL_NAME *name = GENERAL_NAME_new();
name->type = GEN_DNS;
name->d.dNSName = DoSomethingComplicated(...);
Suppose DoSomethingComplicated() was actually fallible and returned
NULL, but the caller forgot to check. They'd now construct a
GENERAL_NAME with a missing field. Previously, this would silently
serialize some garbage (omitted field) or empty string. Now we fail to
encode, but the true error was the uncaught DoSomethingComplicated()
failure. (Which likely was itself a bug.)
Bug: 429
Change-Id: I37fe618761be64a619be9fdc8d416f24ecbb8c46
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49350
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This unexports X509, X509_CINF, X509_NAME_ENTRY, X509_NAME, X509_OBJECT,
X509_LOOKUP_METHOD, X509_STORE, X509_LOOKUP, and X509_STORE_CTX.
Note this means X509_STORE_CTX can no longer be stack-allocated.
Update-Note: Patch cl/390055173 into the roll that includes this. This
unexports most of the X.509 structs, aligning with OpenSSL. Use the
accessor APIs instead.
Bug: 425
Change-Id: I53e915bfae3b8dc4b67642279d0e54dc606f2297
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48985
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This reverts commit be9a86f459. Let's try
this again.
Bug: 375
Change-Id: Ie01cced8017835b2cc6d80e5e81a4508a37fbbaf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48625
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This reverts commit 4251d0d3f6, except
that the reland dates have been updated to not be in the past.
Change-Id: I7812c0e36d87ed1e049ec0a7d92a23efec881a81
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45704
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
When generating a signature with some external signing process, the
caller needs to fill in the TBSCertificate (including the signature
algorithms), serialize the TBSCertificate, and then fill in the
signature.
We have i2d_re_X509_tbs (originally from CT I believe), but there are no
setters for the signature algorithms or the signature. Add
X509_set1_signature_algo, which mirrors upstream's
X509_REQ_set1_signature_algo, and X509_set1_signature_value, which is
new. Upstream has X509_REQ_set0_signature, but that requires the caller
manually assemble an ASN1_BIT_STRING. Taking the byte string seems less
error-prone.
Additionally, add i2d_X509_tbs and i2d_X509_CRL_tbs, for the non-"re"
variants of those APIs. Conscrypt needs to extract the TBS portion of a
certificate and a CRL, to implement X509Certificate.getTBSCertificate()
and X509CRL.getTBSCertList(). There, the aim is to get the data to
verify on an existing immutable certificate. OpenSSL has avoided
exporting the X509_CINF type, which I think is correct, so instead this
mirrors i2d_re_X509_tbs. (This does mean mirroring the confusing i2d
calling convention though.)
These new functions should unblock getting rid of a bunch of direct
struct accesses.
Later on, we should reorganize this header into immutable APIs for
verification and mutable APIs for generation. Even though we're stuck
the mistake of a common type for both use cases, I think splitting up
them up will let us rationalize the caches in the X509 objects a bit.
Change-Id: I96e6ab5cee3608e07b2ed7465c449a72ca10a393
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43784
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Expect to reenable in January 2021.
Change-Id: I364ffcf235901398196c60c45ff1c07fcac3f801
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43024
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Sadly, we need to roll this one back for now, at least until we've
cleared all the test failures it causes. This retains the other checks
in https://boringssl-review.googlesource.com/c/boringssl/+/41746. We're
only rolling back enforcement of the DEFAULT v1 encoding.
Bug: 348, 364
Change-Id: I6a290311f5a5714ff4d5add3ae35ec4550398b32
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42104
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
David Benjamin
Adam Langley