Hi Corey, I think the intent of this is to ensure that if a CRL URL is specified both > in a certificate via the CRLDP and in CCADB, there’s no variation in > casing, trailing slashes, etc. I don’t think it’s establishing a > requirement for all certificates to include CRLDP.
This is correct and ensures there is parity between what we see in certificates and what we see disclosed to the CCADB (except in the rare case of transitory periods). In response to the CRL URL points originally raised by Dimitris and the separate updated information clarity raised by Rob, we’ve created this <https://github.com/mozilla/www.ccadb.org/pull/200/files> PR for a minor version increment of the CCADB Policy to 2.0.1. Continued comments are both welcome and appreciated. Thank you -Chris On Tue, Jul 1, 2025 at 1:25 PM Corey Bonnell <[email protected]> wrote: > Hi Dimitris, > > Comments inline. > > - "MUST match exactly as they appear in the certificates issued by the > corresponding CA" > > > > I think the intent of this is to ensure that if a CRL URL is specified > both in a certificate via the CRLDP and in CCADB, there’s no variation in > casing, trailing slashes, etc. I don’t think it’s establishing a > requirement for all certificates to include CRLDP. I agree that the > language should be improved to make that clear. > > > > Ø If populating a full and complete CRL URL: > > Ø the JSON Array of Partitioned CRL URLs field MUST be empty. > > Ø If populating a JSON Array of Partitioned CRL URLs: > > Ø the full and complete CRL URL MUST be empty. > > > > Can you expand on why it’s useful for both fields to be populated? I think > this requirement to populate only one makes sense, because a full CRL’s > scope will necessarily include all certificates issued by the CA. Thus, any > partitioned CRL information is redundant and need not be specified if a > full CRL is specified. > > > > Thanks, > > Corey > > > > *From:* 'Dimitris Zacharopoulos (HARICA)' via CCADB Public < > [email protected]> > *Sent:* Tuesday, July 1, 2025 12:19 PM > *To:* Chris Clements <[email protected]>; CCADB Public < > [email protected]> > *Cc:* [email protected] <[email protected]>; [email protected] < > [email protected]>; Ben Wilson <[email protected]> > *Subject:* Re: Further Improving the CCADB Policy (FEEDBACK REQUESTED) > > > > > > On 27/6/2025 1:18 π.μ., Chris Clements wrote: > > Hi Dimitris, > > > > It seems switching between full and partitioned CRLs is acceptable so long > as at least one of the two corresponding fields in the CCADB is accurately > populated at all times. If there are multiple full CRL URLs during a period > of transition, at least one of those will need to be disclosed to the > CCADB. With that said, is there a suggested wording change for the CCADB > Policy? > > > Hi Chris, > > I believe my biggest concern comes from the recent change introducing the > following sentence: > > - "MUST match exactly as they appear in the certificates issued by the > corresponding CA" > > Since a CA may change URLs arbitrarily, it is clear that this rule will > fail because there will be a moment in time where an early-issued > end-entity certificate will have "URL A", and a later-issued certificate > will have "URL B". In that case, CCADB will have either "URL A" or "URL B" > causing issues with the policy. > > I suggest removing this sentence. If I recall correctly, the purpose of > this field was to offer an out-of-band CRL checking mechanism that > Certificate Consumers may use in addition to the CRLDP URL in the actual > certificates, or the lack of such an extension. > > To assist with the interchange of full and partitioned URLs, I suggest > removing the following two sentences because as described, the actual > implementation is "either" and not "either or both": > > · If populating a full and complete CRL URL: > > · the JSON Array of Partitioned CRL URLs field MUST be empty. > > · If populating a JSON Array of Partitioned CRL URLs: > > · the full and complete CRL URL MUST be empty. > > > Best regards, > Dimitris. > > > > > Thank you > > -Chris > > On Thursday, June 26, 2025 at 1:37:02 PM UTC-4 [email protected] wrote: > > This is the same for Apple. Whatever is populated will be picked up, so as > long as at least one of the fields is populated at all times CAs can switch > between full and partitioned CRLs as they’d like (from Apple’s > perspective). > > > > Cheers, > > -Clint > > > > On Jun 26, 2025, at 10:27 AM, 'Ben Wilson' via CCADB Public < > [email protected]> wrote: > > > > For CRLite, populating both fields should not create a problem. However, > CAs should not populate the "Full CRL" field with more than one URL. > > Thanks, > > Ben > > > > On Thu, Jun 26, 2025 at 10:56 AM 'Aaron Poulsen' via CCADB Public < > [email protected]> wrote: > > I am also interested to know if a process exists for transitioning from a > full to partitioned CRL (or the reverse) in CCADB. I can't find any > discussions that address this need. > > > > CCADB states that at least one field must be populated. Can we simply > provide values for both fields? > > Aaron > > On Monday, June 23, 2025 at 2:42:46 AM UTC-6 Dimitris Zacharopoulos > (HARICA) wrote: > > Hi Chris, > > Regarding the URLs of CRLDPs, it is non uncommon for a CA to change the > URL of the CRLDP. Obviously, there are redirects until the certificates > with the old URL expire. What is the expectation if there are multiple URLs > to be included in CCADB? > > Also, what is the process for switching from sharded to full CRLs and > vice-versa? > > > Best regards, > Dimitris. > > > > On 17/6/2025 3:45 μ.μ., 'Chris Clements' via CCADB Public wrote: > > All, > > > > The updated CCADB Policy <https://www.ccadb.org/policy> and Incident > Reporting Guidelines <https://www.ccadb.org/cas/incident-report> have > been published with an effective date of *July 15, 2025*. This date is in > line with the expectation that CA Owners will have updated their in-use TLS > server authentication certificate validation methods for publicly-trusted > hierarchies, following the recent > <https://groups.google.com/a/ccadb.org/g/public/c/QOFzi8wGf8Y/m/Tg3ULE0KAgAJ> > CCADB enhancement. > > > > CA Owners are strongly encouraged to align their CCADB disclosures with > the expectations that become effective on July 15, 2025, as soon as > reasonably possible. > > > > Please note, to comply with the updated CRL disclosure requirements > described in Section 6.2 > <https://www.ccadb.org/policy#62-certificate-revocation-list-disclosures>, > it is expected some CAs will need to update existing certificate records > (e.g., modifying CRL disclosures to exactly match those included in > certificates). > > > > Thank you > > -Chris, on behalf of the CCADB Steering Committee > > > > > > On Fri, May 30, 2025 at 4:26 PM Chris Clements <[email protected]> wrote: > > All, > > Thank you to everyone who provided valuable feedback on the proposed > <https://github.com/mozilla/www.ccadb.org/pull/198> updates to the CCADB > Policy and the Incident Reporting Guidelines (IRGs). Both artifacts have > been enhanced thanks to the insightful recommendations and suggestions. > > We want to reiterate the original objectives for this update: > > - Clarifying Root Store Operator expectations for CCADB disclosures. > - Streamlining requirements across different root programs to reduce > redundancy. > - Enhancing the simplicity and readability of the policy. > > We plan to publish the updated CCADB Policy and IRGs later in June, with > an effective date of July 1, 2025. > > We appreciate your continued collaboration in making the CCADB a more > effective and transparent resource for the community. > > -Chris, on behalf of the CCADB Steering Committee > > > > On Fri, May 2, 2025 at 10:48 AM Chris Clements <[email protected]> wrote: > > All, > > Following the community’s recent iteration > <https://groups.google.com/a/ccadb.org/g/public/c/GIBHz9FUjHY/m/XOOLNpOFCAAJ> > and improvement on the updated CCADB Incident Reporting Guidelines > <https://www.ccadb.org/cas/incident-report> (IRGs), the CCADB Steering > Committee has collaborated on an updated draft of the CCADB Policy. > > The set of proposed updates are available here > <https://github.com/mozilla/www.ccadb.org/pull/198>. > > > Objectives for this update include: > > - Clarifying Root Store Operator expectations related to CCADB > disclosures. Some of these clarifications were motivated by public Incident > Reports filed to Bugzilla over the past year. > - Creating opportunities to (a) remove redundant/similar requirements > located across root program policies related to CCADB disclosures and (b) > encourage future simplicity. > - Promoting simplicity and improving readability through a > reorganization of normative and non-normative requirements. > > Additionally, minor updates are proposed to the IRGs (e.g., further > streamlining the incident reporting closure process). > > These proposals should not be considered “final”, but instead a “work > in-progress” that we hope to enhance through community contributions. We > welcome your feedback on these proposed updates and recommendations by *May > 23, 2025*. Please share your thoughts by replying to this email or, > *preferably*, by suggesting edits directly on GitHub. > > Thank you > -Chris, on behalf of the CCADB Steering Committee > > -- > You received this message because you are subscribed to the Google Groups > "CCADB Public" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/ccadb.org/d/msgid/public/CAAbw9mApWKw1J2ZJ2-1ft7LgJK7CDiYvHKLFjtNEiH1EH%3DmYtQ%40mail.gmail.com > <https://groups.google.com/a/ccadb.org/d/msgid/public/CAAbw9mApWKw1J2ZJ2-1ft7LgJK7CDiYvHKLFjtNEiH1EH%3DmYtQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > > > > > -- > You received this message because you are subscribed to the Google Groups > "CCADB Public" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/ccadb.org/d/msgid/public/48947bbc-ca5d-4922-a9fd-9bb74fd82bf9n%40ccadb.org > <https://groups.google.com/a/ccadb.org/d/msgid/public/48947bbc-ca5d-4922-a9fd-9bb74fd82bf9n%40ccadb.org?utm_medium=email&utm_source=footer> > . > > > > -- > You received this message because you are subscribed to the Google Groups > "CCADB Public" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > > To view this discussion visit > https://groups.google.com/a/ccadb.org/d/msgid/public/CA%2B1gtaZh0hjfGtc_6aKeF2vJtQqRh3SLpkTeSdiipDzePVgkOg%40mail.gmail.com > <https://groups.google.com/a/ccadb.org/d/msgid/public/CA%2B1gtaZh0hjfGtc_6aKeF2vJtQqRh3SLpkTeSdiipDzePVgkOg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > > > > > -- > You received this message because you are subscribed to the Google Groups > "CCADB Public" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/ccadb.org/d/msgid/public/4572ee58-1af2-4c4a-90c8-e20bd6c8ea07%40harica.gr > <https://groups.google.com/a/ccadb.org/d/msgid/public/4572ee58-1af2-4c4a-90c8-e20bd6c8ea07%40harica.gr?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "CCADB Public" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/ccadb.org/d/msgid/public/CAAbw9mCcL1gd%3DiC_eq7oMn3%3D0cRW_xhW00G_BG%3D8P5b_Czdumw%40mail.gmail.com.
