On Thursday, January 7, 2021 at 5:00:46 PM UTC-8, Ben Wilson wrote: > This is the last issue that I have marked for discussion in relation to > version 2.7.1 of the Mozilla Root Store Policy > <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/>. > > It is identified and discussed in GitHub Issue #218 > <https://github.com/mozilla/pkipolicy/issues/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 I think this text strikes a good balance. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for End Entity Certificates
Ryan Hurst via dev-security-policy Mon, 11 Jan 2021 11:51:36 -0800
- Policy 2.7.1: MRSP Issue #218: Clari... Ben Wilson via dev-security-policy
- Re: Policy 2.7.1: MRSP Issue #2... Ryan Hurst via dev-security-policy
- Re: Policy 2.7.1: MRSP Issue #2... Corey Bonnell via dev-security-policy
- Re: Policy 2.7.1: MRSP Issue #2... Rob Stradling via dev-security-policy
- Re: Policy 2.7.1: MRSP Issu... Ben Wilson via dev-security-policy
- Re: Policy 2.7.1: MRSP ... Aaron Gable via dev-security-policy
- Re: Policy 2.7.1: M... Ben Wilson via dev-security-policy
- Re: Policy 2.7... Ben Wilson via dev-security-policy