ASN1_ENCODING has a 'modified' bit, but every time it is set, the
contents are both ignored and never filled in again (we don't fill in
the encoding except on parse). That means keeping the underlying buffer
around is just wasting memory. Remove the bit and use the len != 0 to
determine if there's a saved encoding. Replace all the modified bits
with a helper function that drops the encoding.
I don't think we need a separate "present" boolean and can just treat
empty as not saved; a cached value always has a tag and length, so it
cannot be empty. (Even if it could be empty, that would imply the
value's encoding is trivial enough that we probably don't need the saved
encoding to preserve the value.)
Change-Id: I6beda94d33f3799daf85f1397818b9a41e7dd18a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55267
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
https://boringssl-review.googlesource.com/c/boringssl/+/54307 added just
the getters because no one was using the setters yet. But our long
setter *already* implements the int64 version, so just complete the
whole set and deprecate the old long-based APIs.
Change-Id: Ieb793f3cf90d4214c6416ba2f10e641c46403188
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54526
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
ASN1_STRING's representation is confusing. For specifically INTEGER and
ENUMERATED, it lifts the sign bit into the type. While negative serial
numbers aren't actually valid, we do accept them and test code sometimes
uses these APIs to construct them, so amend
https://boringssl-review.googlesource.com/c/boringssl/+/54286 to allow
them.
I've also switched the CRL one to an assert. On reflection, returning 0
for a CRL lookup is failing closed, so it seems better to just continue
to accept the ASN1_STRING, even if it's the wrong type.
Change-Id: I1e81a89700ef14407a78bd3798cdae28a80640cd
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54525
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This adds runtime checks that types which are aliases of ASN1_STRING
are in fact the expected ASN.1 type. Not comprehensive -- I got the
obvious ones from x509.h. These checks are not generally covered by
unit tests, except for one which was easy to test as a sanity-check.
Bug: 445
Change-Id: I8cd689b6b1e6121fce62c7f0ab25fee7e2a0b2ff
Update-Note: Various X.509 functions will now fail given the wrong ASN1_STRING subtype.
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54286
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Types which do not contain an X509_NAME can be const. X509_NAME still
requires some thought. (i2d_X509_NAME can mutate the object and isn't
even thread-safe when modified.)
Bug: 407
Change-Id: Iceafa2b4ea9c4194cfcc3044d90393b5d91f7c11
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53305
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This is a mechanical change generated from the following command:
find crypto/{asn1,pem,x509,x509v3} -name '*.c' -o -name '*.h' | xargs sed -i -e 's/return (\([^;()]*\));/return \1;/'
Change-Id: I957295af96c4aa08d6006e27093fd3a07fb6fe75
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53089
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This CL is the result of the following commands:
for d in asn1 x509 x509v3 pem; do
go run util/convert_comments.go crypto/$d/*.h
go run util/convert_comments.go crypto/$d/*.c
done
Change-Id: If78433f68cb2f913b0de06ded744a5a65540e1cf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53087
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This CL runs the same command as in the preceding CL, but with
'IncludeBraces: true' added to .clang-format. I've split this out
separately because the documentation says:
> Setting this option to true could lead to incorrect code formatting
> due to clang-format’s lack of complete semantic information. As such,
> extra care should be taken to review code changes made by this option.
I've also kept InsertBraces out of .clang-format for now because it's a
fairly recent option, and clang-format fails when it sees unrecognized
options.
Change-Id: I305ea7bb2633704053a1f8de1e11b037b9fc8a76
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53086
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Previously, we did not clang-format a few directories because we had
left them largely untouched. clang-format them now so we're finally more
uniform.
This CL is the result of the following commands:
for d in asn1 x509 x509v3 pem; do
clang-format -i crypto/$d/*.h
clang-format -i crypto/$d/*.c
done
(Written in this funny way because crypto/pem/*.h doesn't match
anything.)
Change-Id: I7f4ca9b3a9c8f07d6556e00e9e84b3c0880ee12e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53085
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This aligns X509_REQ's and X509_CRL's parsers to the changes already
made with X509; we reject invalid versions and check that extensions are
only with the corresponding version. For now, we still allow X509v1 CRLs
with an explicit version, matching certificates. (The DEFAULT question
is moot for X509_REQ because CSRs always encode their version, see RFC
2986.)
In addition to rejecting garbage, this allows for a more efficient
representation once we stop using the table-based parser: X509 and
X509_CRL can just store a small enum. X509_REQ doesn't need to store
anything because the single version is information-less.
Update-Note: Invalid CRL and CSR versions will no longer be accepted.
X509_set_version, etc., no longer allow invalid versions.
Fixed: 467
Change-Id: I33f3aec747d8060ab80e0cbb8ddf97672e07642c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52605
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This fix isn't ideal, given the current space of possible version
values. But rather than make the printing code complicated, we should
make invalid versions impossible. I've left TODOs where that would be
needed.
Bug: 467, 450
Change-Id: I6c9ae97b8454182b0c1ab6ba2e070dc6d7d8b3f4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50767
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
There is no ASN1_TIME_dup, so switch M_ASN1_TIME_dup to ASN1_STRING_dup
as upstream does. Switch M_ASN1_TIME_free to ASN1_TIME_free, also
matching upstream. This is a no-op, but less obviously so:
ASN1_TIME is an MSTRING defined in a_time.c. This defines an MSTRING
ASN1_ITEM. The new/free functions are then generated with
IMPLEMENT_ASN1_FUNCTIONS, which walks the ASN1_ITEM. ASN1_TIME_free then
goes through table-based free function, eventually running
ASN1_primitive_free, which calls ASN1_STRING_free on MSTRINGs.
Change-Id: I1765848a5301ecceeb74f91457351c969b741bb1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44046
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>
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>
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>
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>
David Benjamin
Emily Stark
Adam Langley