These appear to be unused. Some ones of note:
- XN_FLAG_FN_ALIGN breaks with multi-attribute RDNs anyway
- XN_FLAG_FN_NONE is completely pointless
Update-Note: Some seemingly unused XN_FLAG_* values were removed. If
some project fails to build, we can put them back but one shouldn't be
using this function in the first place.
Change-Id: I4d8472e1e31aeec623b4d4e2aea48da7b1ef6798
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58930
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This has been on by default since
cc78b6fdb6,
and now removed from recent bindgen altogether.
Change-Id: Iea4c2a7480fe8b138c375686ca6b36e6d68257b3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58965
Reviewed-by: Nabil Wadih <nwadih@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
These probably don't need their own section. They're just thin wrappers
over other ASN1_TIME functions.
Bug: 426
Change-Id: I8672feb0ca7ba1cf69b56d02d2559de5b80a3ee7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58928
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
They're not used anywhere, as X509_REQ doesn't expose the underlying
STACK_OF(X509_ATTRIBUTE) anyway. They're also very thin wrappers over
the stack functions, so just delete them and inline them into X509_REQ
functions.
While I'm here, I've tidied up the add1_attr_by_* functions to reduce an
unnecessary copy.
Change-Id: Iec002c83ab7ad7267314e98866d680d12a82e971
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58927
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Also organize the low-level signature verification functions. I missed
those in the first pass.
Bug: 426
Change-Id: I9c93d643d8f0f77a35ee132f31377ba447f2f2f1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58926
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
I had a branch lying around to rewrite X509_NAME_print(_ex) because
those functions are a disaster, but it needs more work and probably
isn't high priority. In the meantime, document what we've got.
Also tidy up X509_print_ex slightly. m was completely unused and
some variable declarations could be moved closer to their definition.
Bug: 426
Change-Id: I24295048c36268c745f579ad66f34736cfe6830f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58925
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
(This change breaks running on Android. But it's close to what we used
for non-Android FIPS testing so is useful to have on the record.)
This change adds testing of the run-time break tests: the pair-wise
consistency tests and the RNG test.
It also switches to using two test_fips binaries: an unmodified one for
showing a clean up and testing the integrity test, and a test_fips_break
which makes integrity test failures non-fatal (for KAT testing) and
which allows the run-time tests to be triggered.
Change-Id: Id2787723059cfb17cc2d22013ad66b985ef86701
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53885
Reviewed-by: David Benjamin <davidben@google.com>
Auto-Submit: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
On Android, when running from an APK, |tmpfile| does not work. See
b/36991167#comment8.
Change-Id: I1415471907e61da5e8c8d1530a2b915fcd991d53
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58845
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
NIST has deprecated the test that we were using and replaced it with the
one that this change switches BoringSSL to using.
Change-Id: Iff975cda33153f8db42d9c01457d104c502485b9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58787
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This relands
https://boringssl-review.googlesource.com/c/boringssl/+/54606, which was
temporarily reverted.
Update-Note: By default, clients will now require RSA server
certificates used in TLS 1.2 and earlier to include the keyEncipherment
or digitalSignature bit. keyEncipherment is required if using RSA key
exchange. digitalSignature is required if using ECDHE_RSA key exchange.
If unsure, TLS RSA server signatures should include both, but some
deployments may wish to include only one if separating keys, or simply
disabling RSA key exchange. The latter is useful to mitigate either the
Bleichenbacher attack (from 1998, most recently resurfaced in 2017 as
ROBOT), or to strengthen TLS 1.3 downgrade protections, which is
particularly important for enterprise environments using client
certificates (aka "mTLS") because, prior to TLS 1.3, the TLS client
certificate flow was insufficiently encrypted or authenticated. Without
reflecting an RSA key exchange disable into key usage, and then the
client checking it, an attacker can spoof a CertificateRequest as coming
from some server.
This aligns with standard security requirements for using X.509
certificates, specified in RFC 5280, section 4.2.1.3, and reiterated in
TLS as early as TLS 1.0, RFC 2246, section 7.4.2, published 24 years ago
on January 1999. Constraints on usage of keys are important to mitigate
cross-protocol attacks, a class of cryptographic attacks that is
well-studied in the literature.
We already checked this for each of ECDSA, TLS 1.3, and servers
verifying client certificates, so this just fills in the remaining hole.
As a result, this change is also important for avoiding some weird
behaviors when configuration changes transition a server in or out of
this hole. (We've seen connection failures get misattributed to TLS 1.3
when it was really a certificate misconfiguration.)
Chrome has also enforced this for some time with publicly-trusted
certificates. As a temporary measure for callers that need more time,
the SSL_set_enforce_rsa_key_usage API, added to BoringSSL in January
2019, still exists where we need to turn this off.
Fixed: 519
Change-Id: I91bf2cfb04c92aec7875e640f90ba6f837146dc1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58805
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Change-Id: I32a40a73f96e029ac9096af826d15b22d9dcad28
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58745
Auto-Submit: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
HRSS itself remains in libcrypto because there are some direct users of
it. But this will let it be dropped by the linker in many cases.
Change-Id: I870eda30c9ed1d08693c770e9e7df45a2711b7df
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58645
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
These are already unused, though add and add_alias will need more work.
In doing so, simplify the X509V3_EXT_DYNAMIC business. I added some
cleanup calls to https://boringssl-review.googlesource.com/2208, but
that should have been in the error-handling path of
X509V3_EXT_add_alias, the only case that cares about this.
Update-Note: Removed unused API.
Bug: 590
Change-Id: Idd97366d90d7aab0ca2e020c76a7c8065b3dd7ff
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58765
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
I don't believe these codepaths have ever been run. All the built-in
X509V3_EXT_METHODs are ASN1_ITEM-based, as are all callers I found of
X509V3_EXT_add and X509V3_EXT_add_list.
Also document not to use those APIs because they're pointless and (for
now) not even thread-safe. Making them thread-safe is doable, but it'd
add rwlock contention in certificate verification, unless we first
rework certificate verification to ignore custom registrations, because
it never uses them anyway. But that only proves that this whole feature
was pointless, so this time may be better spent trying to get rid of
this API.
Update-Note: Externally-installed X509V3_EXT_METHODs now must be
ASN1_ITEM-based. I believe all existing ones already are. If there are
any that aren't, let us know. We'll either revert this for now, or
export a way to implement custom ASN1_ITEMs, or, most likely, try to
move the caller off custom X509V3_EXT_METHODs altogether. Like most of
OpenSSL's other global registration APIs, this one is unsafe (two
callers may conflict) and there isn't much reason to register it with
the library because OpenSSL doesn't do much with the registration
anyway.
Bug: 590
Change-Id: Ice0e246d50069e10e6cca8949f60fac474d0846c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58687
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This reverts a small portion of
8c8629bfd8. The parsers for ANY remain
unchanged, but we inadvertently changed a corner case of ASN1_PRINTABLE
MSTRINGs. This is a huge mess.
utype in these switch cases is usually the type of the ASN1_ITEM, but,
with ANY and MSTRING, it is the tag of the value we found. (An MSTRING
or "multi-string" is a CHOICE of string-like types.)
When parsing ANY, this is moot because the is_supported_universal_type
logic ensures we'll never pass in an invalid type. When encoding ANY,
this only happens if you manually construct such an ASN1_TYPE.
MSTRINGs *should* be similar because of the bitmask they apply on tag
types. However, there is one MSTRING type whose bitmask,
B_ASN1_PRINTABLE, includes B_ASN1_UNKNOWN. ASN1_tag2bit, arbitrarily
maps eight unsupported tags to B_ASN1_UNKNOWN and instead of zero. These
are:
- ObjectDescriptor
- EXTERNAL
- REAL
- EMBEDDED PDV
- RELATIVE-OID
- TIME (note this is not the same as the X.509 Time CHOICE type)
- [UNIVERSAL 15], which is not even a defined type!
- CHARACTER STRING
(ENUMERATED is also mapped to B_ASN1_UNKNOWN, but it's supported.)
These eight tags were previously accepted in d2i_X509_NAME but
8c8629bfd8 inadvertently started rejecting
them. For now, restore the default in the switch/case so that we accept
them again. Per https://crbug.com/boringssl/412, attribute values are
ANY DEFINED BY types, so we actually should be accepting *all* types. We
do not, because B_ASN1_PRINTABLE is completely incoherent. But because
ANY is the correct type, going from the original incoherent set, to
this new, smaller incoherent set is arguably a regression.
This is a minimal fix. Long-term, we should handle that ANY correctly,
and avoid unexpected ASN1_STRING type values, by mapping all unsupported
types to V_ASN1_OTHER. This would allow us to support all types
correctly. A follow-up change will do that.
Update-Note: The X.509 name parser will go back to accepting a handful
of universal tag types that were inadvertently rejected in
8c8629bfd8. It is extremely unlikely that
anyone uses these as they're unsupported, obscure types. This CL also
makes our ASN1_TYPE encoder slightly more permissive again, if the
caller manually constructs an legacy in-memory representation of an
unsupported tag. But the follow-up change will restore the stricter
behavior.
Bug: 412, 561
Change-Id: Ia44a270f12f3021154761a1cd285707416d8787e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58705
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Change-Id: I6e53434246f3fef06d4f88924bfe1cbfad0543e8
Bug: chromium:1414562
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58205
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Change-Id: I43dd18f7d70ee06ca25affad0ab06e5d5ef8263d
Signed-off-by: wangjiale3 <wangjiale3@xiaomi.corp-partner.google.com>
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58489
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Also unexport PEM_proc_type and PEM_dek_info. They're never called
externally, just private functions within one file. Also, while I'm
here, fix the include guard on asn1/internal.h.
Bug: 516
Change-Id: I6961a65f638e7b464a8c349663898a954d7826b4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58548
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This was replaced with the upstream-compatible SSL_CIPHER_standard_name
in https://boringssl-review.googlesource.com/17324. It looks like we've
since migrated everything off the old name, so let's just remove it.
Update-Note: SSL_CIPHER_get_rfc_name calls can be replaced with
SSL_CIPHER_standard_name, which is also more efficient as it avoids an
allocation and copy. If anyone's using this function and can't easily
migrate, let us know and we can put this back for a little longer.
Change-Id: I6bce40a8a146671429641a5dbff6f614006a9a1c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58665
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Change-Id: I06773ff0c42c68f1f2d4c581f52b71008c4cdb3c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58625
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Auto-Submit: Adam Langley <agl@google.com>
Change-Id: Idcf0fdcc88af509958e56052c1925f3f695bc3e3
Signed-off-by: wangjiale3 <wangjiale3@xiaomi.corp-partner.google.com>
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58487
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
We support BIO_gets on three BIOs. They're all slightly different. File
BIOs have the NUL truncation bug. fd BIOs swallow the embedded newline.
This CL fixes the second issue and updates the BIO_gets test to cover
all three.
See also upstream's https://github.com/openssl/openssl/pull/3442
Update-Note: BIO_gets on an fd BIO now returns the newline, to align
with memory and file BIOs. BIO_gets is primarily used in the PEM parser,
which tries to tolerate both cases, but this reduces the risk of some
weird bug that only appears in fd BIOs.
Change-Id: Ia8ffb8c67b6981d6ef7144a1522f8605dc01d525
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58552
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Change-Id: I4288988f3742f14b15f80a3023b716392a667631
Signed-off-by: wangjiale3 <wangjiale3@xiaomi.corp-partner.google.com>
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58485
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Normally these would be size_t, but we try to reduce per-connection
memory in libssl, so use uint8_t, then add asserts, checks, and casts as
appropriate.
Bug: 516
Change-Id: Ibdd9d88f2b05173daee2db5f6fb77d619302bfdf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58547
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The outl <= 0, etc., checks are actually redundant with logic in the
wrappers, but it seems easier to just add the check and avoid worrying
about it. Maybe someday we'll make the internals use size_t and this
will be moot.
Bug: 516
Change-Id: I0bea5ac325c79b9765d822c816661fe4f2bcd4cc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58546
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
There was even a bug where we returned -1 out of a function whose
callers use !.
Change-Id: Ic815ea9f013bcbca41ef84b9ffa9fb867f716aa6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58465
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Our test coverage for BIOs isn't great. Fill in missing memory BIO
tests, in preparation for reworking it a bit to be size_t-clean.
Change-Id: I77aeab93d6d9275c65e998d517463f4cc10efcf3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58545
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This updated value is not in the private use area and can hopefully be
more stable over time.
Change-Id: Ieda34ec0f356cfd03365973f611a6edc23431e29
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58525
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Passes test vectors, and should be constant time, but is currently
not optimized and neither the API nor the standard is stable.
Change-Id: I89b90877e023a43ee7238e11b86065444ab3bdec
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57845
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
If we see a critical policy constraints extension, we have two options:
We can either process it, which requires running policy validation, or
reject the certificate. We and OpenSSL do neither by default, which
means we may accept certificate chains that we weren't supposed to.
This fixes it by enabling X.509 policy validation unconditionally and
makes X509_V_FLAG_POLICY_CHECK moot. As a side effect, callers no longer
need to do anything for CVE-2023-0466.
This is the opposite of [0]'s advice, which instead recommends skipping
the feature and rejecting critical policy contraints. That would be a
good move for a new X.509 implementation. Policy validation is
badly-designed, even by X.509's standards. But we have OpenSSL's history
of previously accepting critical policy constraints (even though it
didn't check it). I also found at least one caller that tests a chain
with policy constraints, albeit a non-critical one.
We now have an efficient policy validation implementation, so just
enable it.
Of course, fixing this bug in either direction has compatibility risks:
either we take on the compat risk of being newly incompatible with
policyConstraints-using PKIs, or we take on the compat risk of newly
rejecting certificates that were invalid due to a policy validation
error, but no one noticed. The latter case seems safer because the chain
is unambiguously invalid.
Update-Note: X.509 certificate verification (not parsing) will now
notice policy-validation-related errors in the certificate chain. These
include syntax errors in policy-related extensions, and chains with a
requireExplicitPolicy policy constraint that are valid for no
certificate policies. Such chains are unambiguously invalid. We just did
not check it before by default. This is an obscure corner of X.509 and
not expected to come up in most PKIs.
[0] https://www.ietf.org/archive/id/draft-davidben-x509-policy-graph-01.html#section-3.4.4
Fixed: 557
Change-Id: Icc00c7797bb95fd3b14570eb068543fd83cda7b9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58426
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
OpenSSL interprets NULL and empty lists as {anyPolicy}. I intended to
implement this, but didn't quite get the NULL case right. Fix this and
add a test.
Change-Id: I50dbf02695f424697e28a6e0ec4fd50b2822f44f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58425
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
This was not thread-safe and, until the previous CL, egregiously so. No
one uses this API, so remove it.
Update-Note: Various unused functions for registering named
X509_VERIFY_PARAMs were removed. These functions only exist to make
X509_VERIFY_PARAM_lookup return a custom value. Instead, applications
that want a particular X509_VERIFY_PARAM can just configure it directly,
rather than stashing it in library-global state and then looking it back
up with X509_VERIFY_PARAM_lookup.
Change-Id: I8d532a1a137c7abbc131f2cb5d12ba94e5728e2d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58386
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This is a double-pointer and both layers should be const. This matches
OpenSSL 1.1.1, so in addition to being more const-correct, we're more
OpenSSL-compatible.
Update-Note: Anything that defines a comparison function would need to
fix the type signature. I found only one external caller, Envoy, that
defines it. https://github.com/envoyproxy/envoy/pull/25051 fixes it.
(That we hadn't run into the upstream incompatibility suggests this is
just not a feature folks use outside the library much.)
Bumping BORINGSSL_API_VERSION, in case I missed any, and there's some
caller where we can't just use C++14 generic lambdas to smooth it over.
Fixed: 498
Change-Id: I8f07ff42215172aa65ad8819acf69b63d6d8e54c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56190
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
These functions need a lot more work, documentation, warnings
that using them isn't a good idea, and really we should just remove them
entirely.
But, for now, this is a minimal fix to the most egregious of issues: not
only are the functions themselves not thread-safe (i.e. you must call it
in some program-global initialization), but using them puts you in a
state where future uses of the X.509 library are not thread-safe! Fix
the latter by sorting the list at the point we're already mutating
things.
Re-sorting a list after every addition is not a particularly sensible
implementation, but we can assume these lists will only ever contain
O(1) entries.
(The sort calls date to
https://boringssl-review.googlesource.com/c/boringssl/+/27304, but the
issue was there before. Prior to that CL, sk_FOO_find implicitly sorted
the list. That CL made sk_FOO_find itself a const operation, necessary
for this, and just added explicit sk_FOO_sort calls to preserve the
existing behavior, initially.)
Change-Id: I063b8e708eaf17dfe66c5a3e8d33733adb3297e9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58385
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This function is probably not what you want. I think the
X509V3_EXT_METHOD and ASN1_STRING_TABLE_add stuff are the only cases
where you actually need an OID. Those, themselves, have problems with
conflicting registrations and aren't really necessary.
ASN1_STRING_TABLE_add has a similar warning on it. X509V3_EXT_METHOD is
not yet documented, but should get a similar warning when we document
it.
Change-Id: I173918a3f7db25059ed078b2f67b23acfb43033d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58365
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
alg was a copy-paste error.
Change-Id: I4c591bb98f7da853c79679727d49a00c7c65ad91
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58305
Reviewed-by: Alex Gaynor <alex.gaynor@gmail.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
I mistakenly thought no one needed X509 as an ASN1_ITEM, but that wasn't
true. wpa_supplicant relies on this. Restore this and add a test for it.
As with the rest of the rewrite, this is currently a little tedious. I'm
hoping that, as the internals are rewritten with CBS and CBB, we can
establish some cleaner patterns and abstractions.
Bug: 547
Change-Id: I761ee058f8ec916b2ec7f4730a764d46d72f1f10
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58285
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Now that the preceding CL has isolated the X.509 signature hack, we can
apply the strictness across the legacy parser. This is particularly
important for the TBSCertificate parser, where it is ambiguous which
value one checks the signature over. (Officially, you're supposed to
re-encode as DER. In practice, people don't do this.)
This change means many of our primitive types are actually parsed as
DER. I've removed the bug references in the comment in the documentation
where I believe they're finally correct.
Update-Note: Non-minimal lengths in certificates are no longer accepted,
as required for standards compliance. The one exception is the signature
field, where we still carry an exception. Some of this was already
enforced by libssl's parser.
Bug: 354
Change-Id: I57cfa7df9e1ec5707390e9b32fe1ec6b5d8172f9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58186
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
David Benjamin
Andres Erbsen
Adam Langley
Adam Langley
Nabil Wadih
Bob Beck
Steven Valdez
Adam Langley
wangjiale3
Sophie Schmieg