| commit | 6dcce800371dd5f3cb35a16a18b99fcfadf213ab | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Mon Nov 02 18:16:14 2020 -0500 |
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Tue Nov 03 23:43:59 2020 +0000 |
| tree | d8eff2c86b444163ec42b38bb0c5cc1e293e1fa8 | |
| parent | f18638cca14d0b02617785e848a5afaa2715f71a [diff] |
Add functions for manipulating X.509 TBS structures. 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>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
Project links:
There are other files in this directory which might be helpful: