I think that an explicit carve-out for time-scoped CRLs is a very good idea.
In the case that this change to the MRSP is adopted, I suspect that LE would scope CRLs by notAfter quite tightly, with perhaps one CRL per 24 or even 6 hours of issuance. We would pick a small interval such that we could guarantee that each CRL would still be a reasonable size even in the face of a mass revocation event. Producing CRLs at that rate, it would be very valuable to be able to gracefully age CRLs out once there is no possibility for a revocation status update for any certificate in their scope. Aaron On Sun, Jan 24, 2021 at 10:22 AM Ben Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > All, > > Another suggestion came in for clarification that hasn't been raised on the > list yet, so I'll try and explain the scenario here. > > Normally, a CA must publish and update its CRLs until the end of the CA > certificate's expiration. However, I think that some CAs partition their > CRLs based on issuance time, e.g., all certificates issued during January > 2021. And all of those certificates would expire after the applicable > validity period. I think CAs don't continue to regenerate or reissue those > types of partitioned CRLs which only contain certificates that have > expired. So maybe we need to add an express exception that allows CAs to > omit those obsolete CRLs from the JSON file -- as long as the JSON file > contains the equivalent of a "full and complete" CRL. > > Thoughts? > > Thanks, > Ben > > > On Wed, Jan 13, 2021 at 8:57 AM Rob Stradling <r...@sectigo.com> wrote: > > > Hi Ben. > > > > > *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* > > > > As a consumer of this data (crt.sh), I'd much prefer to see "Full CRL > > Issued By This CA" and "the URL for the JSON file" as 2 separate fields > in > > the CCADB. CAs would then be expected to fill in one field or the other, > > but not both. Is that possible? > > > > To ensure that these JSON files can be programmatically parsed, I suggest > > specifying the requirement a bit more strictly. Something like this: > > "...or the URL for a file that contains only a JSON Array, whose > > elements are URLs of DER encoded CRLs that when combined are the > equivalent > > of 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. > > > > Most Root Certificates are "enabled for server certificate issuance". > > Obviously CAs shouldn't issue leaf certs directly from roots, but > > nonetheless the technical capability does exist. However, currently CAs > > can't edit Root Certificate records in the CCADB, which makes populating > > these new field(s) "in all situations" rather hard. > > > > Since OneCRL covers revocations of intermediate certs, may I suggest that > > CAs should only be required to populate these new field(s) in > intermediate > > certificate records (and not in root certificate records)? > > > > Relatedly, "A CA technically capable of...that the CCADB field" seems > > wrong. CCADB "CA Owner" records don't/won't contain the new field(s). > > Similar language elsewhere in the policy (section 5.3.2) says "All > > certificates that are capable of being used to..." (rather than "All > > CAs..."). > > > > Technically-constrained intermediate certs don't have to be disclosed to > > CCADB, but "in all situations where the CA is enabled for server > > certificate issuance" clearly includes technically-constrained > > intermediates. How would a CA populate the "Full CRL Issued By This CA" > > field for a technically-constrained intermediate cert that has > > (legitimately) not been disclosed to CCADB? > > > > ------------------------------ > > *From:* dev-security-policy < > dev-security-policy-boun...@lists.mozilla.org> > > on behalf of Ben Wilson via dev-security-policy < > > dev-security-policy@lists.mozilla.org> > > *Sent:* 08 January 2021 01:00 > > *To:* mozilla-dev-security-policy < > > mozilla-dev-security-pol...@lists.mozilla.org> > > *Subject:* Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for > > End Entity Certificates > > > > CAUTION: This email originated from outside of the organization. Do not > > click links or open attachments unless you recognize the sender and know > > the content is safe. > > > > > > 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mozilla.org%2Fen-US%2Fabout%2Fgovernance%2Fpolicies%2Fsecurity-group%2Fcerts%2Fpolicy%2F&data=04%7C01%7Crob%40sectigo.com%7C65685639e2bf45be5f6f08d8b370cf17%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637456644391892862%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=shOhNu8IGrT0iSSt2LY4E6LQlsr6y435Vv%2BNezNCh98%3D&reserved=0 > > >. > > It is identified and discussed in GitHub Issue #218 > > < > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F218&data=04%7C01%7Crob%40sectigo.com%7C65685639e2bf45be5f6f08d8b370cf17%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637456644391892862%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Zb0abofrs3IaJzX9nkEnFf6RbyCemLYIi%2B7l4SmUz5U%3D&reserved=0 > > > > 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy&data=04%7C01%7Crob%40sectigo.com%7C65685639e2bf45be5f6f08d8b370cf17%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637456644391892862%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2B3uVDNUQ7qJ1afOf7O6zDkwVB8HrEiqrQSPdVir0A88%3D&reserved=0 > > > _______________________________________________ > 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
