x509_rsa_ctx_to_pss returns an error when trying to make an X509_ALGOR
for an arbitrary RSA-PSS salt length. This dates to the initial commit
and isn't in OpenSSL, so I imagine this was an attempt to ratchet down
on RSA-PSS parameter proliferation.
If the caller explicitly passes in md_size, rather than using the -1
convenience value, we currently fail. Allow those too and add an error
to the error queue so it is easier to diagnose.
Change-Id: Ia738142e48930ef5a916cad5326f15f64d766ba5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43824
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: 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>
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>
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>
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>
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
Adam Langley