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.
