Hi Ben, A few follow-up questions and comments: 1) What are the expectations regarding availability for such CRLs? Do the availability requirements in BR 4.10.2 stand for these CRLs even if such CRL pointers are not encoded in end-entity certificates? 2) What is the expectation for populating the CRLDP in end-entity S/MIME certificates? If no change in policy for S/MIME end-entity certificates is desired, then I think the text should be further qualified with "CAs SHOULD place the URL for the associated CRL within the crlDistributionPoints extension of issued *server* certificates".
Thanks, Corey On Thursday, January 7, 2021 at 8:00:46 PM UTC-5, 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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
