This allows us to avoid calling any NSSCertificateDB methods on the main
thread or allocating memory for xpconnect wrappers of cert objects.
Differential Revision: https://phabricator.services.mozilla.com/D97970
The RDD process can no longer work without having access to win32k ; enabling this pref would lead to a crash on Nightly and failure to work elsewhere.
Differential Revision: https://phabricator.services.mozilla.com/D97753
This patch enables pre-spawn CIG in the RDD process.
If CIG prevents a module in the executable's Import Directory Table, Windows totally
fails to launch a process. So we add a policy rule of `SUBSYS_SIGNED_BINARY` for
all files under the directory containing the executable such as mozglue.dll, and
modules injected via Import Directory Table. The latter ones will be blocked by our
blocklist with `REDIRECT_TO_NOOP_ENTRYPOINT` (bug 1659438).
Differential Revision: https://phabricator.services.mozilla.com/D96933
This removes telemetry regarding baseline requirements sections 9.2.1 and 9.2.2
(subject alternative name and subject common name) that is no longer necessary.
More specifically, this removes the histogram categories
BR_9_2_1_SUBJECT_ALT_NAMES and BR_9_2_2_SUBJECT_COMMON_NAME.
Differential Revision: https://phabricator.services.mozilla.com/D97507
2020-11-18 Kevin Jacobs <kjacobs@mozilla.com>
* lib/ssl/ssl3con.c, lib/ssl/tls13con.c, lib/ssl/tls13ech.c:
Bug 1654332 - Fixup a10493dcfcc9: copy ECHConfig.config_id with
socket r=jcj
A late review change for ECH was for the server to compute each
ECHConfig `config_id` when set to the socket, rather than on each
connection. This works, but now we also need to copy that config_id
when copying a socket, else the server won't find a matching
ECHConfig to use for decryption.
[3eacb92e9adf] [tip]
2020-11-17 Kevin Jacobs <kjacobs@mozilla.com>
* automation/abi-check/expected-report-libssl3.so.txt,
cmd/tstclnt/tstclnt.c, cpputil/tls_parser.h,
gtests/ssl_gtest/libssl_internals.c,
gtests/ssl_gtest/libssl_internals.h, gtests/ssl_gtest/manifest.mn,
gtests/ssl_gtest/ssl_auth_unittest.cc,
gtests/ssl_gtest/ssl_custext_unittest.cc,
gtests/ssl_gtest/ssl_extension_unittest.cc,
gtests/ssl_gtest/ssl_gtest.gyp,
gtests/ssl_gtest/ssl_tls13compat_unittest.cc,
gtests/ssl_gtest/tls_agent.cc, gtests/ssl_gtest/tls_agent.h,
gtests/ssl_gtest/tls_connect.cc, gtests/ssl_gtest/tls_connect.h,
gtests/ssl_gtest/tls_ech_unittest.cc,
gtests/ssl_gtest/tls_esni_unittest.cc,
gtests/ssl_gtest/tls_filter.cc, gtests/ssl_gtest/tls_filter.h,
lib/ssl/SSLerrs.h, lib/ssl/manifest.mn, lib/ssl/ssl.gyp,
lib/ssl/ssl3con.c, lib/ssl/ssl3ext.c, lib/ssl/ssl3ext.h,
lib/ssl/ssl3exthandle.c, lib/ssl/ssl3exthandle.h,
lib/ssl/ssl3prot.h, lib/ssl/sslencode.c, lib/ssl/sslencode.h,
lib/ssl/sslerr.h, lib/ssl/sslexp.h, lib/ssl/sslimpl.h,
lib/ssl/sslinfo.c, lib/ssl/sslsecur.c, lib/ssl/sslsock.c,
lib/ssl/sslt.h, lib/ssl/tls13con.c, lib/ssl/tls13con.h,
lib/ssl/tls13ech.c, lib/ssl/tls13ech.h, lib/ssl/tls13esni.c,
lib/ssl/tls13esni.h, lib/ssl/tls13exthandle.c,
lib/ssl/tls13exthandle.h, lib/ssl/tls13hashstate.c,
lib/ssl/tls13hashstate.h:
Bug 1654332 - Update ESNI to draft-08 (ECH). r=mt
This patch adds support for Encrypted Client Hello (draft-ietf-tls-
esni-08), replacing the existing ESNI (draft -02) support.
There are five new experimental functions to enable this:
- SSL_EncodeEchConfig: Generates an encoded (not BASE64) ECHConfig
given a set of parameters.
- SSL_SetClientEchConfigs: Configures the provided ECHConfig to the
given socket. When configured, an ephemeral HPKE keypair will be
generated for the CH encryption.
- SSL_SetServerEchConfigs: Configures the provided ECHConfig and
keypair to the socket. The keypair specified will be used for HPKE
operations in order to decrypt encrypted Client Hellos as they are
received.
- SSL_GetEchRetryConfigs: If ECH is rejected by the server and
compatible retry_configs are provided, this API allows the
application to extract those retry_configs for use in a new
connection.
- SSL_EnableTls13GreaseEch: When enabled, non-ECH Client Hellos will
have a "GREASE ECH" (i.e. fake) extension appended. GREASE ECH is
disabled by default, as there are known compatibility issues that
will be addressed in a subsequent draft.
The following ESNI experimental functions are deprecated by this
update:
- SSL_EncodeESNIKeys
- SSL_EnableESNI
- SSL_SetESNIKeyPair
In order to be used, NSS must be compiled with
`NSS_ENABLE_DRAFT_HPKE` defined.
[a10493dcfcc9]
* lib/ssl/ssl3con.c, lib/ssl/sslencode.c, lib/ssl/sslencode.h,
lib/ssl/tls13con.c, lib/ssl/tls13con.h:
Bug 1654332 - Buffered ClientHello construction. r=mt
This patch refactors construction of Client Hello messages. Instead
of each component of the message being written separately into
`ss->sec.ci.sendBuf`, we now construct the message in its own
sslBuffer. Once complete, the entire message is added to the sendBuf
via `ssl3_AppendHandshake`.
`ssl3_SendServerHello` already uses this approach and it becomes
necessary for ECH, where we use the constructed ClientHello to
create an inner ClientHello.
[d40121ba59ba]
2020-11-13 J.C. Jones <jjones@mozilla.com>
* automation/abi-check/expected-report-libnss3.so.txt, automation/abi-
check/expected-report-libnssutil3.so.txt, automation/abi-check
/previous-nss-release, lib/nss/nss.h, lib/softoken/softkver.h,
lib/util/nssutil.h:
Set version numbers to 3.60 Beta
[5e7b37609f22]
Differential Revision: https://phabricator.services.mozilla.com/D97492
This patch uses nsICertStorage.hasPriorData() and a new local field on the
CRLite filter Remote Settings collection to avoid re-downloading and
re-processing CRLite filters and stashes that have already been put into
cert_storage.
Differential Revision: https://phabricator.services.mozilla.com/D97381
Some PSM services need to be initialized on the main thread. Before this patch,
this was achieved by dispatching a synchronous task to the main thread in the
event that a different thread was attempting to acquire a given service for the
first time. However, with the upcoming removal of the nested event loop in the
XPCOM service instantiation code (see other patches in this bug), this can
cause a deadlock. This patch avoids the deadlock by removing the synchronous
dispatch and ensuring that these services get initialized on the main thread
relatively early, when PSM itself is initialized.
Differential Revision: https://phabricator.services.mozilla.com/D94145
This method only is async in order to allow callers to wait for a process switch
triggered by the call to `loadURI` to be finished before resolving. With
DocumentChannel, we should never trigger a process switch eagerly like this
again, so we don't need any of the async behaviour here anymore.
This part is largely mechanical changes to tests, removing the `await` calls on
`loadURI`, and a follow-up part will remove the actual async logic from
`BrowserTestUtils.loadURI`.
Differential Revision: https://phabricator.services.mozilla.com/D94641
2020-11-13 J.C. Jones <jjones@mozilla.com>
* lib/nss/nss.h, lib/softoken/softkver.h, lib/util/nssutil.h:
Set version numbers to 3.59 final
[c5d760cbe8d0] [NSS_3_59_RTM] <NSS_3_59_BRANCH>
2020-11-10 J.C. Jones <jjones@mozilla.com>
* .hgtags:
Added tag NSS_3_59_BETA1 for changeset c3cb09a7d087
[06e965656f08]
Differential Revision: https://phabricator.services.mozilla.com/D97041
The new infrastructure consists of a separate bridge between the content and the
parent process and a separate local storage database in the parent process.
The new infrastructure can be used for storing and sharing of private browsing
data across content processes.
This patch only creates necessary infrastructure, actual enabling of storing and
sharing of data across content processes will be done in a follow-up patch.
Differential Revision: https://phabricator.services.mozilla.com/D96562
Eventually it needs to be possible for osclientcerts to differentiate between
keys that can and can't perform modern cryptography (RSA-PSS being the main
issue). This is because PSM and NSS need to know not to offer to use a key that
can't actually perform the signing operation in question. However, the current
implementation can be very slow if the user has slow hardware with a number of
keys on it. Since PSM and NSS changes are required to make use of this
differentiation anyway, the best approach for now seems to be to skip this step.
Differential Revision: https://phabricator.services.mozilla.com/D96148
Bug 1634065 will involve changing when nsCertOverrideService gets initialized.
It turns out that doing this causes
services/crypto/tests/unit/test_crypto_random.js to fail various assertions in
the JS engine. It's unclear what the underlying issue is, but the failures
happen as a result of marking nsCertOverrideService as a shutdown blocker
unconditionally in its initialization. This patch works around this by marking
the service as a blocker only when there's a write event happening, which is
arguably more correct anyway.
Differential Revision: https://phabricator.services.mozilla.com/D95899
2020-11-03 Kevin Jacobs <kjacobs@mozilla.com>
* gtests/common/testvectors/hmac-sha256-vectors.h,
gtests/common/testvectors/hmac-sha384-vectors.h,
gtests/common/testvectors/hmac-sha512-vectors.h,
gtests/common/testvectors_base/test-structs.h,
gtests/pk11_gtest/manifest.mn, gtests/pk11_gtest/pk11_gtest.gyp,
gtests/pk11_gtest/pk11_hmac_unittest.cc:
Bug 1672823 - Add Wycheproof HMAC test cases. r=jcj
[97751cd6d553] [tip]
* gtests/common/testvectors/hkdf-sha1-vectors.h,
gtests/common/testvectors/hkdf-sha256-vectors.h,
gtests/common/testvectors/hkdf-sha384-vectors.h,
gtests/common/testvectors/hkdf-sha512-vectors.h,
gtests/common/testvectors/hkdf-vectors.h,
gtests/common/testvectors_base/test-structs.h,
gtests/common/wycheproof/genTestVectors.py,
gtests/pk11_gtest/manifest.mn,
gtests/pk11_gtest/pk11_hkdf_unittest.cc:
Bug 1672823 - Add Wycheproof HKDF test cases. r=bbeurdouche
[5a02ca2617cf]
* gtests/common/testvectors/dsa-vectors.h,
gtests/common/testvectors_base/test-structs.h,
gtests/common/wycheproof/genTestVectors.py,
gtests/common/wycheproof/source_vectors/dsa_test.json,
gtests/pk11_gtest/manifest.mn,
gtests/pk11_gtest/pk11_dsa_unittest.cc,
gtests/pk11_gtest/pk11_gtest.gyp:
Bug 1672823 - Add Wycheproof DSA test cases. r=jcj
[3ce42ead87f9]
* lib/dev/devslot.c, lib/dev/devt.h:
Bug 1663661 - Guard against NULL token in nssSlot_IsTokenPresent.
r=jcj
This patch addresses locking inconsistency in
`nssSlot_IsTokenPresent` by retaining the slot lock for the duration
of accesses to `slot->token`. This is already done correctly
elsewhere. As a side effect, this introduces an ordering
requirement: we take `slot->lock` followed by `session->lock`.
[0ed11a5835ac]
2020-10-30 Kevin Jacobs <kjacobs@mozilla.com>
* lib/pk11wrap/pk11pars.c:
Bug 1670835 - Fixup for 6f79a7695812, add missing return value
check. r=rrelyea
[424974716ef0]
Differential Revision: https://phabricator.services.mozilla.com/D96073
Do not use SPDY or HTTP3 for internal security operations. It could result
in the silent upgrade to ssl, which in turn could require an SSL
operation to fulfill something like an OCSP fetch, which is an
endless loop.
Differential Revision: https://phabricator.services.mozilla.com/D95295
This method only is async in order to allow callers to wait for a process switch
triggered by the call to `loadURI` to be finished before resolving. With
DocumentChannel, we should never trigger a process switch eagerly like this
again, so we don't need any of the async behaviour here anymore.
This part is largely mechanical changes to tests, removing the `await` calls on
`loadURI`, and a follow-up part will remove the actual async logic from
`BrowserTestUtils.loadURI`.
Differential Revision: https://phabricator.services.mozilla.com/D94641
2020-10-26 Robert Relyea <rrelyea@redhat.com>
* lib/libpkix/pkix_pl_nss/pki/pkix_pl_ocspresponse.c,
tests/ssl/ssl.sh:
Bug 1672291 libpkix OCSP failures on SHA1 self-signed root certs
when SHA1 signatures are disabled. r=mt
When libpkix is checking an OCSP cert, it can't use the passed in
set of trust anchors as a base because only the single root that
signed the leaf can sign the OCSP request. As a result it actually
checks the signature of the self-signed root when processing an OCSP
request. This fails of the root cert signature is invalid for any
reason (including it's a sha1 self-signed root cert and we've
disabled sha1 signatures (say, by policy)).
Further investigation indicates the difference between our classic
code and the current code is the classic code only checks OCSP
responses on leaf certs. In the real world, those responses are
signed by intermediate certificates (who won't have sha1 signed
certificates anymore), so our signature processing works just fine.
pkix checks OCSP on the intermediate certificates as well, which are
signed by the root cert. In this case the root cert is a chain of 1,
and is effectively a leaf. This patch updates the OCSP response code
to not check the signatures on the single cert if that cert is a
selfsigned root cert. This requires bug 391476 so we still do the
other validation checking on the certs (making sure it's trusted as
a CA).
[035110dfa0b9] [tip]
2020-10-23 Robert Relyea <rrelyea@redhat.com>
* lib/certhigh/certvfypkix.c,
lib/libpkix/pkix_pl_nss/module/pkix_pl_nsscontext.c,
lib/libpkix/pkix_pl_nss/module/pkix_pl_nsscontext.h,
lib/libpkix/pkix_pl_nss/pki/pkix_pl_cert.c,
lib/libpkix/pkix_pl_nss/pki/pkix_pl_ocspresponse.c,
tests/ssl/ssl.sh:
Bug 1672291 libpkix OCSP failures on SHA1 self-signed root certs
when SHA1 signatures are disabled.
When libpkix is checking an OCSP cert, it can't use the passed in
set of trust anchors as a base because only the single root that
signed the leaf can sign the OCSP request. As a result it actually
checks the signature of the self-signed root when processing an OCSP
request. This fails of the root cert signature is invalid for any
reason (including it's a sha1 self-signed root cert and we've
disabled sha1 signatures (say, by policy)).
Further investigation indicates the difference between our classic
code and the current code is the classic code only checks OCSP
responses on leaf certs. In the real world, those responses are
signed by intermediate certificates (who won't have sha1 signed
certificates anymore), so our signature processing works just fine.
pkix checks OCSP on the intermediate certificates as well, which are
signed by the root cert. In this case the root cert is a chain of 1,
and is effectively a leaf. This patch updates the OCSP response code
to not check the signatures on the single cert if that cert is a
selfsigned root cert. This requires bug 391476 so we still do the
other validation checking on the certs (making sure it's trusted as
a CA).
[97f69f7a89a1]
2020-10-26 Kevin Jacobs <kjacobs@mozilla.com>
* gtests/ssl_gtest/tls_filter.cc:
Bug 1644209 - Fix broken SelectedCipherSuiteReplacer filter. r=mt
This patch corrects the `SelectedCipherSuiteReplacer`filter to
always parse the `session_id` variable (`legacy_session_id` for TLS
1.3+). The previous code attempted to skip it in 1.3+ but did not
account for DTLS wire versions, resulting in intermittent failures.
[a79d14b06b4a]
2020-10-26 Daiki Ueno <dueno@redhat.com>
* gtests/ssl_gtest/ssl_tls13compat_unittest.cc, lib/ssl/ssl3con.c,
lib/ssl/sslimpl.h:
Bug 1672703, always tolerate the first CCS in TLS 1.3, r=mt
Summary: This flips the meaning of the flag for checking excessive
CCS messages, so it only rejects multiple CCS messages while the
first CCS message is always accepted.
Reviewers: mt
Reviewed By: mt
Bug #: 1672703
[b03a4fc5b902]
2020-10-23 Robert Relyea <rrelyea@redhat.com>
* automation/abi-check/expected-report-libnssutil3.so.txt,
gtests/mozpkix_gtest/pkixcert_signature_algorithm_tests.cpp,
lib/nss/nss.h, lib/ssl/ssl3con.c, lib/util/SECerrs.h,
lib/util/nssutil.def, lib/util/secerr.h, tests/policy/policy.sh:
Bug 1670835 Crypto Policy Support needs to be updated with
disable/enable support
Policy update
Current state of the nss policy system:
The initial policy patch focused on getting policy working well in
handling ssl. The policy infrastructure used two existing NSS
infrastructure: 1) Algorithm policies tied the OIDS and 2) the ssl
policy constraints first created to handle export policy
restrictions. To make loadable policies work, we added a couple of
new things: 1) a policy parser to the secmod infrastructure which
allows us to set algorithm policies based on a config file. This
file had two sections: disallow= and allow=. Disallow turned off
policy bits, and allow turned them on. Disallow was always parsed
first, so you could very strictly control your policy map by saying
disallow=all allow={exclusive list of allowed algorithms} 2) a new
NSS_Option() value that allowed the policy parser to set integer
values (like minimum tls version) based on the data in the policy
parser. 3) SSL code which is run at ssl_init time that reads the
algorithm policies and maps the results to SSL policies.
The resulting loaded policy code, in general, sets the boundaries of
what it possible, actually enable/disable of ssl cipher suites are
still under program control, and the builtin NSS default values. The
only consession to configuration is if a cipher is disallowed by
policy, it is also disabled. Allowing a cipher suite by policy that
wasn't already enabled, however, doesn't enable that policy by
default. Inside the policy restrictions, applications can still make
their own decisions on configuration and preference.
At the time the policy system was designed, there were 3 additional
features, which were designed, but not specified: disable, enable,
and lock.
disable and enable work just like disallow and allow, except the
specify what the default settings are. This would allow the policy
file to change the underlying default in the case where the
application doesn't try to configure ssl on it's own.
lock would make either the policy or configuration 'locked' meaning
once the lock has been executed, no further changes to those
configurations would be allowed.
What is needed:
We have a need for the following additional features:
1) we want to turn more of the sha-1 hash function off by default.
We still need sha-1 digest because it's used in many non-secure
cases, but we do want to disable more sha-1 signature usage.
Currently only CERT-SIGNATURE and various hmac usages in SSL ciphers
can be controlled by policy. We want to disallow a greater range of
signature (that is signature use in general).
2) we want to disable more ciphers by default, but need a way to
have certain policies (like LEGACY) turn them back on, so that our
shipped system is more secure by default.
What this patch provides:
1) A new policy flag NSS_USE_ALG_IN_ANY_SIGNATURE was added. The
cryptohi code which exports the NSS sign/verify high level code now
checks the hash and signing algorithm against this new policy flag
and fails if the policy isn't available. New key words were added to
the policy parser for 'all-signature', which implies all signature
flags at once, and 'signature', which maps to NSS_USE_ANY_SIGNATURE.
NOTE: disable=all/signature and disable=all/all-signature are
effective equivalent because cert-signatures eventually call the low
level signature functions, but disable=all allow=rsa-pss/all-
signature and disable=all allow=rsa-pss/signature are different in
that the latter allows all rsa-pss signature and the latter allows
rsa-pss signatures, but no on certificates (or on smime in the
future) Also new keywords were added for rsa-pkcs, rsa-pss, and
ecdsa for signature algorithms (along with dsa).
2) This patch implements disable and enable. These functions only
work on SSL configuration. In the future SMIME/CMS configuration
could also be added. Because the policy system is parsed and handled
by NSS, and SSL configuration is handled in SSL, we use the same
Apply code we used to apply ssl policy to set the inital
configuration. The configured enable/disable state is configured in
the ALGORTHIM policy system, where one bit says the enable/disable
value is active and another bit which gives it's state.
3) two locks have been implented, policy-lock and ssl-lock. These
are specified in the parser as flags (flags=policy-lock,ssl-lock).
The policy locks all the policy changes: ssl_policy, algorithm
policy, and options. It is implemented by two new exported
functions: NSS_IsPolicyLocked() and NSS_LockPolicy(). The first
allows applications to test if the policy is locked without having
to try changing the policy. The various policy set functions check
the NSS_IsPolicyLocked() function and returns SEC_ERROR_POLICY_LOCK
if it's true. The ssl-lock changes the state of the policy to
locked, and the state cannot be changed back without shutting down
NSS. The second is implemented by setting a new Option called
NSS_DEFAULT_LOCKS and the NSS_DEFAULT_SSL_LOCK flag. The idea is we
can add an SMIME lock in the future. SSL checks the
NSS_DEFAULT_SSL_LOCK flag before trying to set the cipher suite
value, and blocks the change if it's set.
4) sslpolicy tests were updated to test the enable, disable, flags
=policy-lock, flags=ssl-lock and the new signature primitives.
5) policy tests were updated to be able to run standalone (like all
the other all.sh tests), as well as new tests to detect when no
signing algorithms have been enabled.
What is not in the patch
1) S/MIME signature policy has been defined for a while, but never
hooked up. 2) S/MIME export policy needs to be connected back to the
algorithm policy system just like the ssl cipher suites already are.
3) S/MIME default configuration needs to be connected back to the
policy system. 4) ECC Curve policy needs to be hooked up with the
signature policy (probably should create a generic 'key meets
policy' function and have every call it).
[6f79a7695812]
* automation/abi-check/expected-report-libnss3.so.txt,
gtests/pk11_gtest/pk11_rsaoaep_unittest.cc, lib/nss/nss.def,
lib/pk11wrap/pk11pub.h, lib/pk11wrap/pk11skey.c:
Bug 1666891 - Add PK11_Pub{Wrap,Unwrap}SymKeyWithMechanism
r=mt,rrelyea
Summary
This is useful for RSA-OAEP support.
The CKM_RSA_PKCS_OAEP mechanism requires a CK_RSA_PKCS_OAEP_PARAMS
be present for PKCS#11 calls. This provides required context for
OAEP. However, PK11_PubWrapSymKey lacks a way of providing this
context and historically silently converted CKM_RSA_PKCS_OAEP to
CKM_RSA_PKCS when a RSA key is provided. Introducing a new call will
let us indicate parameters and potentially support other mechanisms
in the future. This call mirrors the earlier calls introduced for
RSA-PSS: PK11_SignWithMechanism and PK11_VerifyWithMechanism.
The CKM_RSA_PKCS_OAEP mechanism requires a CK_RSA_PKCS_OAEP_PARAMS
be present for PKCS#11 calls. This provides required context for
OAEP. However, PK11_PubUnwrapSymKey lacks a way of providing this
context, and additionally lacked a way of indicating which mechanism
type to use for the unwrap operation (instead detecting it by key
type). Introducing a new call will let us indicate parameters and
potentially support other mechanisms in the future.
Signed-off-by: Alexander Scheel <ascheel@redhat.com>
[33f920fcd175]
2020-10-23 Petr Sumbera <petr.sumbera@oracle.com>
* coreconf/config.gypi:
Bug 1667989 - coreconf/config.gypi should allow correct linking on
Solaris r=kjacobs,bbeurdouche
[e3bd9c2f9259]
2020-10-23 Kevin Jacobs <kjacobs@mozilla.com>
* automation/abi-check/expected-report-libnss3.so.txt,
gtests/pk11_gtest/pk11_find_certs_unittest.cc, lib/nss/nss.def:
Bug 1668123 - Export CERT_AddCertToListHeadWithData and
CERT_AddCertToListTailWithData. r=jcj
[0f15b05daeed]
2020-07-30 Benjamin Beurdouche <bbeurdouche@mozilla.com>
* lib/ckfw/builtins/certdata.txt:
Bug 1634584 - Set CKA_NSS_SERVER_DISTRUST_AFTER for Trustis FPS Root
CA. r=kjacobs
[7076e78ddafe]
2020-10-14 J.C. Jones <jjones@mozilla.com>
* lib/util/secasn1d.c:
Bug 1663091 - Remove unnecessary assertions in the streaming ASN.1
decoder r=kjacobs
The streaming ASN.1 decoder had assertions that, on debug builds,
blocked embedding indefinite-length fields inside of definite-length
fields/contexts, however that behavior does work correctly, and is
valid ASN.1: it tends to happen when wrapping a signature around
existing ASN.1-encoded data, if that already-encoded data had an
indefinite length.
Really these two assertion were just overzealous. The conditional
after the asserts handle the case well, and memory sanitizers have
not found issue here either.
[d0153cc0c464]
Differential Revision: https://phabricator.services.mozilla.com/D95093