These are a bit of a mess. Callers almost never handle the error
correctly.
Change-Id: I85ea6d4c03cca685f0be579459efb66fea996c9b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43804
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@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>
We already support this, but there wasn't a test for it.
Change-Id: I14304b99b312fcf729703cf175ec41e3e60db363
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43704
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This is a looser reland of
https://boringssl-review.googlesource.com/c/boringssl/+/41804, which was
reverted in
https://boringssl-review.googlesource.com/c/boringssl/+/42804.
Enforcing that the ECDSA parameters were omitted rather than NULL hit
some compatibility issues, so instead allow either forms for now. To
align with the Chromium verifier, we'll probably want to later be
stricter with a quirks flag to allow the invalid form, and then add a
similar flag to Chromium. For now, at least try to reject the completely
invalid parameter values.
Update-Note: Some invalid certificates will now be rejected at
verification time. Parsing of certificates is unchanged.
Bug: b/167375496,342
Change-Id: I1cba44fd164660e82a7a27e26368609e2bf59955
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43664
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
It's a lot easier to copy certificates to and from x509_test.cc when
there isn't an indent to worry about. Note this does stick a newline in
front of each string, but the PEM parsers don't care.
Change-Id: I06aff263a2470596e8c50564c198693cfdbf9c59
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43285
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>
In upstream, this returns a const pointer, so we should match.
Update-Note: Callers may need to update their calls of
X509_get0_extensions, but I believe everything affected has been fixed.
Change-Id: Ic92660e18868cc681399ba4fc3f47ea1796fb164
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42884
Reviewed-by: Adam Langley <agl@google.com>
Conscrypt will need these functions. Also fix a bug in
X509_get_extension_flags's error-handling. While I'm here, add
X509_CRL_get0_extensions for completeness. Nothing uses this yet, but
this could later be an alternative to avoid Conscrypt's mess with
templates.
Change-Id: I9393b75fcf53346535e6a4712355be081baa630d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42744
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
X509_STORE_CTX_init is documented upstream to allow a NULL store and has
logic to account for it. However, attempting to use such an
X509_STORE_CTX crashes in X509_verify_cert due to the
additional_untrusted logic we added.
Moreover, before that change, it still crashes because
X509_STORE_CTX_get1_issuer (the default get_issuer hook) assumes
ctx->ctx (the store) is non-null. This was also true in upstream but
later fixed in https://github.com/openssl/openssl/pull/6001. However,
without a store, there is no trust anchor, so this is not very useful.
Reject NULL stores in X509_STORE_CTX_init and remove the logic allowing
for a NULL one.
Thanks to Danny Halawi for catching this.
Update-Note: X509_STORE_CTX_init will now fail when the store is NULL,
rather than report success, only to crash later in X509_verify_cert.
Breakage should thus be limited to code which was passing in a NULL
store but never used the resulting X509_STORE_CTX.
Change-Id: I9db0289612cc245a8d62d6fa647d6b56b2daabda
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42728
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Cast between T* and ASN1_VALUE* directly, rather than messing with
unions. This is necessary to avoid UB in C++ and is a strict aliasing
violation in C too. (While C does allow type-punning in unions, pointers
to union fields have weird rules. I suspect most of our unions should be
reworked.)
Change-Id: Ibe274a7df5d5826f8c5f335255d196e9b7587105
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42726
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This reverts commit 9dd9d4fc24.
BUG=b/167375496,342
Original change's description:
> Check AlgorithmIdentifier parameters for RSA and ECDSA signatures.
>
> This aligns with the Chromium certificate verifier, which allows NULL or
> empty for RSA and requires empty for ECDSA.
>
> Bug: 342
> Change-Id: I34acf68f63b4d133dd47b73144b2f27224c499ee
> Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41804
> Reviewed-by: Adam Langley <agl@google.com>
> Commit-Queue: David Benjamin <davidben@google.com>
TBR=agl@google.com,davidben@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: If8f136a09fea68e64c9f4f9ffae88b6209ede124
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42804
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Actually making crypto/asn1 and crypto/x509 const-correct will be a tall
order, between all the hidden caches, non-const ASN.1 macros, and
ambiguity between mutable and immutable getters. But upstream
const-corrected a number of things, so align with them. (In particular,
it is not currently possible to usefully use a non-const X509_NAME.)
I think I've gotten most of x509.h. I started going through x509v3.h,
but all the conf bits take non-const char* pointers, which shows up in
the public (but probably unused) X509V3_CONF_METHOD, so I've left it
alone in this CL.
For some reason, OpenSSL made X509_get_subject_name a const-to-non-const
function but kept X509_get_serialNumber uniformly non-const while adding
a uniformly const X509_get0_serialNumber. I've just mirrored this for
compatibility's sake.
Change-Id: Ia33a7576165cf2da5922807fc065f1f114b0f84c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42584
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
OpenSSL renamed the preferred spelling of X509_set_notBefore to
X509_set1_notBefore, etc., in 568ce3a583a17c33feacbf5028ece9f7f0680478.
Add the set1 names and update uses within the library.
Change-Id: Ib211e356da9de963990ad2b330249383ccfef7e5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42524
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@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>
This is partially imported from upstream's
54dbf42398e23349b59f258a3dd60387bbc5ba13 which does something similar.
In doing so, remove the pkcs8->broken field, which is a remnant of some
parsing hacks we long since removed (PKCS8_set_broken). The immediate
motivation is, if this sticks, this would make it easier to detach
i2d_PKCS8_PRIV_KEY_INFO and d2i_PKCS8_PRIV_KEY_INFO from the old ASN.1
code.
Update-Note: Direct accesses of PKCS8_PRIV_KEY_INFO now need to use the
accessors. Code search suggests no one uses the fields. Even the
accessors are virtually unused (the one thing which uses it doesn't need
it).
Bug: chromium:1102458
Change-Id: I57054de3fe412079f7387dc99291250e873b1471
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42006
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Code which targets OpenSSL won't use EVP_parse_public_key. X509_PUBKEY
is fairly deeply tied to the old ASN.1 stack, but there's no reason for
i2d_PUBKEY and friends to be. Move them to crypto/evp and reimplement as
wrappers over our functions.
Bug: chromium:1102458
Change-Id: Ic11766acdac797602e4abe1253b0efe33faef298
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42005
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
David Benjamin
Adam Langley
Adam Langley