> 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.
Hi Chris. You may recall that I expressed surprise about this "expectation" at the recent CABForum F2F. Allow me to explain. The announcement for the recent <https://groups.google.com/a/ccadb.org/g/public/c/QOFzi8wGf8Y/m/Tg3ULE0KAgAJ> CCADB enhancement said (emphasis mine): - "The CCADB was updated to add the following TLS Certificate Domain and IP Address Control Validation Methods as *options* for selection by CA Owners" - "CA Owners implementing any of these methods *can* disclose their use" I haven't been able to find any previous CCADB announcement regarding the Validation Methods field, and I also can't find any language in the newly updated CCADB Policy or in any of the Root Store policies that requires this field to be populated. In contrast, there are clear MUST requirements for populating certain other fields (e.g., https://www.ccadb.org/policy#62-certificate-revocation-list-disclosures). The reason for my surprise is that an "expectation" sounds like "SHOULD" or "MUST", whereas "options" and "can" sound like "MAY". I have no problem with aiming to comply with clearly labelled SHOULD and MUST requirements that have achievable effective dates and that are enshrined in official policies, but ISTM that your "expectation" here is an implied and backdated "SHOULD" or "MUST" that is neither clearly labelled nor enshrined in policy. Is there some other basis for your "expectation" that I've missed? On Tuesday, June 17, 2025 at 1:45:30 PM UTC+1 Chris Clements 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/34be89fd-cfa5-4ad2-a477-25128a69de22n%40ccadb.org.
