ASN1_OBJECTs are awkward. Sometimes they are static, when returned from
OBJ_nid2obj, and sometimes they are dynamic, when parsed from
crypto/asn1.
Most structures in crypto/asn1 need to support unknown OIDs and thus
must own their ASN1_OBJECTs. But they also may be initialized with
static ones in various APIs, such as X509_ALGOR_set0. To make that work,
ASN1_OBJECT_free detects static ASN1_OBJECTs and is a no-op.
Functions like X509_ALGOR_set0 take ownership, so OpenSSL has them take
a non-const ASN1_OBJECT*. To match, OBJ_nid2obj then returns a non-const
ASN1_OBJECT*, to signal that it is freeable.
However, this means OBJ_nid2obj's mutability doesn't match its return
type. In the fork, we switched OBJ_nid2obj to return const. But, in
doing so, we had to make X509_ALGOR_set0 and X509_PUBKEY_set0_param take
const ASN1_OBJECT, even though they would actually take ownership of
dynamic ASN1_OBJECTs. There are also a few internal casts with a TODO to
be const-correct.
Neither situation is ideal. (Perhaps a more sound model would be to copy
static ASN1_OBJECTs before putting them in most structs. But that would
not match current usage.) But I think aligning with OpenSSL is the
lesser evil here, since it avoids misleading set0 functions. Managing
ownership of ASN1_OBJECTs is much more common than mutating them. To
that end, I've added a note that ASN1_OBJECTs you didn't create must be
assumed immutable[*].
Update-Note: The change to OBJ_nid2obj should be compatible. The changes
to X509_PUBKEY_set0_param and X509_ALGOR_set0 may require fixing some
pointer types.
[*] This is *almost* honored by all of our functions. The exception is
c2i_ASN1_OBJECT, which instead checks the DYNAMIC flag as part of the
object reuse business. This would come up if we ever embedded
ASN1_OBJECTs directly in structs.
Change-Id: I1e6c700645c12b43323dd3887adb74e795c285b9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46164
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The X509 version APIs confuse everyone, including our own tests
(v3name_test.cc was using the wrong value). Introduce constants. Also
document which version to use for each type. It is extra confusing that,
although certificates and CRLs use the same Version enum, RFC5280
defines X.509 v3 certificates with X.509 v2 CRLs. (There are no v3
CRLs.)
I'll send a similar patch to OpenSSL to keep upstream aligned.
Change-Id: If096138eb004156d43df87a6d74f695b04f67480
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45944
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
See also CVE-2020-1971, f960d81215ebf3f65e03d4d5d857fb9b666d6920, and
aa0ad2011d3e7ad8a611da274ef7d9c7706e289b from upstream OpenSSL.
Unlike upstream's version, this CL opts for a simpler edipartyname_cmp.
GENERAL_NAME_cmp is already unsuitable for ordering, just equality,
which means there's no need to preserve return values from
ASN1_STRING_cmp. Additionally, the ASN.1 structure implies most fields
cannot be NULL.
(The change from other to x400Address is a no-op. They're the same type.
Just x400Address is a little clearer. Historical quirks of the
GENERAL_NAME structure.)
Change-Id: I4b0ffe8e931c8ef916794a486e6a0d6d684c0cc1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44404
Reviewed-by: Adam Langley <agl@google.com>
At one point in the SSLeay days, all the ASN1_STRING typedefs were
separate structs (but only in debug builds) and the M_ASN1_* macros
included type casts to handle this.
This is long gone, but we still have the M_ASN1_* macros. Remove the
casts and switch code within the library to call the macros. Some
subtleties:
- The "MSTRING" types (what OpenSSL calls its built-in CHOICEs
containing some set of string types) are weird because the M_FOO_new()
macro and the tasn_new.c FOO_new() function behave differently. I've
split those into a separate CL.
- ASN1_STRING_type, etc., call into the macro, which accesses the field
directly. This CL inverts the dependency.
- ASN1_INTEGER_new and ASN1_INTEGER_free, etc., are generated via
IMPLEMENT_ASN1_STRING_FUNCTIONS in tasn_typ.c. I've pointed
M_ASN1_INTEGER_new and M_ASN1_INTEGER_free to these fields. (The free
function is a no-op, but consistent.)
- The other macros like M_ASN1_BIT_STRING_dup largely do not have
corresponding functions. I've aligned with OpenSSL in just using the
generic ASN1_STRING_dup function. But some others, like
M_ASN1_OCTET_STRING_dup have a corresponding ASN1_OCTET_STRING_dup
function. OpenSSL retained these, so I have too.
Update-Note: Some external code uses the M_ASN1_* macros. This should
remain compatible, but some type errors may have gotten through
unnoticed. This CL restores type-checking.
Change-Id: I8656abc7d0f179192e05a852c97483c021ad9b20
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44045
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>
See 309e73dfe067b3b774ef6f57bf665f41373a81ca from upstream, though note
that v3_alt.c's fix was rewritten. (We don't have sk_reserve, and I
don't think their fix was quite right anyway.)
Change-Id: Ieabd19d87d4628658324b212cce2ed3ce451ad22
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43284
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>
This is needed to fix all the config APIs to take const char *. I've
split it out as it's the only incompatible half of the change.
Update-Note: External definitions of X509V3_CONF_METHOD will need fix
the types of their functions. There should not be any of these (probably
hide this struct), but if there are, this aligns with upstream OpenSSL.
Change-Id: I6e760cfbca5d3f408215b8f3744acd1fd7f31391
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42727
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Although extensions are accessible via X509_get_ext_d2i, OpenSSL's X509
object carries caches of a number of extensions. OpenSSL added accessors
for some of these in 1.1.0 (X509_get0_subject_key_id) and 1.1.1d (the
others), so mirror this. Note that, although they look like simpler
getters, the error-handling is tricky.
(For now I'm just looking to mirror OpenSSL's accessors and finally make
the structs opaque. Go's x509.Certificate structure also recognizes a
collection of built-in certificate fields, but error-handling is in the
parser. That could be one path out of this cached fields mess, at the
cost of making the parse operation do more work.)
Change-Id: I051512aa296bd103229ba6eb2b5639d79e9eb63f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42624
Reviewed-by: Adam Langley <agl@google.com>
These aren't used within the verifier and no one ever extracts them.
Update-Note: Parsers for these two extensions are removed. Parsing the
types directly or passing NID_sxnet and NID_pkey_usage_period into
X509V3_get_d2i, or *_get_ext_d2i will no longer work.
Change-Id: I359e64466fd0c042eda45c41cbc0843ebb04df9f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42585
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>
David Benjamin
Adam Langley