I got that wrong. It passes ownership to the caller. It calls
X509_PUBKEY_get which bumps the refcount.
Change-Id: I46b7eabcf56f68bb1f745bc2f64091640e97c0bf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44084
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
At the time, we hadn't taught clang-format how to handle STACK_OF
correctly.
Change-Id: Ia90c3bf443846a07eddaea5044b724027552ed30
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43964
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: I77e08b88afa8a1f4e28449bf728eccc2c2f6f372
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43944
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
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>
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>
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>
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