All, We are going to postpone the resolution of this Issue #218 and the addition of language to address the "Full CRL" until MRSP version 2.8. Thanks for your input thus far. Ben
On Thu, Feb 25, 2021 at 10:59 AM Ben Wilson <bwil...@mozilla.com> wrote: > As placeholder in the Mozilla Root Store Policy, I'm proposing the > following sentence for section 6.1 - "A CA MUST ensure that it populates > the CCADB with the appropriate 'full CRL' in the CCADB revocation > information field pertaining to certificates issued by the CA > <https://www.ccadb.org/cas/fields#revocation-information> for each > intermediate CA technically capable of issuing server certificates." (The > hyperlink isn't active yet until we have the CCADB language and > implementation clarified, per Kathleen's recent email and responses > thereto.) Here it is on GitHub - > https://github.com/BenWilson-Mozilla/pkipolicy/commit/26c1ee4ea8be1a07f86253e38fbf0cc043e12d48. > Caveat - other browsers, such as Apple, will likely have more encompassing > implementation requirements for when to populate these "full CRL" fields. > > On Mon, Jan 25, 2021 at 10:16 AM Aaron Gable <aa...@letsencrypt.org> > wrote: > >> 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
