Re: Extending Android Device Compatibility for Let's Encrypt Certificates

[Man Ho (Certizen) via dev-security-policy]

I think it is a mistake to assume that the "intermediate" (i.e. your 
ISRG Root X1 cross-signed by DST Root CA X3) is the same certificate as 
your self-signed ISRG Root X1.  The "intermediate" can only be chained 
up to expired DST Root CA X3.


On 08-Jan-21 1:31 AM, Aaron Gable via dev-security-policy wrote:

Clients using OpenSSL 1.0.x were failing, because
they couldn't recognize that one of the intermediates in the chain was in
their own trust store.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for End Entity Certificates

[Ben Wilson via dev-security-policy]

This is the last issue that I have marked for discussion in relation to
version 2.7.1 of the Mozilla Root Store Policy
.
It is identified and discussed in GitHub Issue #218
 for the MRSP.

I will soon update everyone on the status of the other 13 discussion items
already presented, as some of them are in need of revision based on
comments received thus far.

While subsection (b) of section 7.1.2.3 of the Baseline Requirements makes
a cRLDistributionPoint (CDP) in end entity certificates optional, Mozilla
still desires that CRL-based revocation information be available because
CRLite uses CRLs to construct its revocation filters.  (Apple also uses
such CRL information in its certificate validation processes and, as I
understand, is making a similar request of CAs with respect to the new
CCADB field, discussed below.)

While all such CRL information is needed, large CRLs are disfavored because
of the time they take to download and process.  Thus, CAs shard, partition,
or "scope" their CRLs into smaller chunks. Section 5 of RFC 5280 explains,
"Each CRL has a particular scope.  The CRL scope is the set of certificates
that could appear on a given CRL. … A complete CRL lists all unexpired
certificates, within its scope, that have been revoked for one of the
revocation reasons covered by the CRL scope.  A *full and complete CRL*
lists all unexpired certificates issued by a CA that have been revoked for
any reason." (Emphasis added.)

There is a new field in the CCADB for CAs to include information needed for
browsers or others to construct a "full and complete CRL", i.e. to gather
information from CAs that don't include the CRL path to their "full and
complete CRL" in end entity certificates they issue. This new CCADB field
is called "Full CRL Issued By This CA" and is located under the heading
"Pertaining to Certificates Issued by this CA." Rather than condition the
requirement that CAs fill in this information in the CCADB only when they
don't include a CDP to a full and complete CRL, I propose that this new
CCADB field be populated in all situations where the CA is enabled for
server certificate issuance. In cases where the CA shards or partitions its
CRL, the CA must provide a JSON-based list of CRLs that when combined are
the equivalent of the full and complete CRL.

Proposed language to add to section 6 of the Mozilla Root Store Policy is
as follows:

*CAs SHOULD place the URL for the associated CRL within the
crlDistributionPoints extension of issued certificates. A CA MAY omit the
crlDistributionPoint extension, if permitted by applicable requirements and
policies, such as the Baseline Requirements. *

*A CA technically capable of issuing server certificates MUST ensure that
the CCADB field "Full CRL Issued By This CA" contains either the URL for
the full and complete CRL or the URL for the JSON file containing all URLs
for CRLs that when combined are the equivalent of the full and complete CRL*
.


I look forward to your comments and suggestions.

Ben
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Extending Android Device Compatibility for Let's Encrypt Certificates

[Aaron Gable via dev-security-policy]

In cases where we expect OpenSSL to be validating the chain, we expect that
ISRG Root X1 is also in the trust store (unlike older versions of Android,
where we know that it hasn't been added). As such, there will be two
certificates in the chain which are also in the local trust store: ISRG
Root X1 and the expired DST Root CA X3.

It is my understanding that OpenSSL 1.1.0+, with the `trusted_first` method
as the default chain-building method, will go through the following steps:
1) Receive the chain "EE <-- R3 <-- ISRG Root X1 (cross-signed by DST Root
CA X3)" from the server
2) Look to see if it can complete this chain using certificates from
`-CAfile`, `-CApath`, or `-trusted`
3) See that ISRG Root X1 is already trusted
4) Return this chain, which successfully verifies.

The evidence that this works on OpenSSL 1.1.0+ comes from the very similar
situation this past May. In that case, many servers were serving the chain
"EE <-- Sectigo RSA Domain Validation Secure Server CA <-- USERTrust RSA
Certification Authority <-- AddTrust External CA Root". In that situation,
both the USERTrust RSA Certification Authority and the AddTrust External CA
Root were in various trust stores, and then the AddTrust External CA Root
expired. Clients which were using OpenSSL 1.1.0+ did not begin to fail at
that time, because they were still able to trust the USERTrust RSA
Certification Authority. Clients using OpenSSL 1.0.x were failing, because
they couldn't recognize that one of the intermediates in the chain was in
their own trust store.

If this understanding is incorrect or missing something, we'd love to be
informed.

Thanks again,
Aaron

On Thu, Jan 7, 2021 at 1:10 AM Kurt Roeckx via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 2021-01-07 01:48, Aaron Gable wrote:
> > As mentioned in the blog post, and as we'll elaborate on further in an
> > upcoming post, one of the drawbacks of this arrangement is that there
> > actually is a class of clients for which chaining to an expired root
> > doesn't work: versions of OpenSSL prior to 1.1. This is the same failure
> > mode as various clients ran into on May 30th of 2020, when the AddTrust
> > External CA root expired.
>
> I'm not sure why you mention OpenSSL prior to 1.1. There was a bug in
> 1.1.1h that no longer checked for expired roots, but it was fixed in
> 1.1.1i. OpenSSL has no plan to allow expired roots by default.
>
>
> Kurt
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Extending Android Device Compatibility for Let's Encrypt Certificates

[Kurt Roeckx via dev-security-policy]

On 2021-01-07 01:48, Aaron Gable wrote:

As mentioned in the blog post, and as we'll elaborate on further in an
upcoming post, one of the drawbacks of this arrangement is that there
actually is a class of clients for which chaining to an expired root
doesn't work: versions of OpenSSL prior to 1.1. This is the same failure
mode as various clients ran into on May 30th of 2020, when the AddTrust
External CA root expired.


I'm not sure why you mention OpenSSL prior to 1.1. There was a bug in 
1.1.1h that no longer checked for expired roots, but it was fixed in 
1.1.1i. OpenSSL has no plan to allow expired roots by default.



Kurt
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy