Updates to the CCADB Root Inclusion Public Discussion Process

[Ben Wilson]

Hello everyone,

As part of our ongoing efforts to improve transparency, consistency, and access to information for root certificate inclusion requests, the CCADB Steering Committee is proposing some changes to parts of the CCADB Root Inclusion Public Discussion process. Specifically, we want to adjust the messaging that begins the 6-week public discussion period. 

What is changing

Historically, announcement emails have included a long, manually copied outline of case data from the CCADB. This has typically included organization details, certificate fingerprints, audit statements, test websites, and incident summaries presented inline in the email body.

Going forward, announcement emails will be more consistent, and will primarily:

• Provide some specifics from the CCADB Root Inclusion Request case;

• Provide a direct link to a new public printable case report (example);

• Provide a link to the entirety of the CA’s Incident Report history from Bugzilla; and

• Highlight any additional information needed to orient reviewers to the case.

The case details will now be seen in the CCADB’s printable public report, rather than duplicated in the email itself. We encourage reviewers to use the printable CCADB report as the primary reference when evaluating open root inclusion cases and when submitting feedback during the discussion period.

What the new printable report includes

The new CCADB printable public report consolidates and structures all case information under clear subject headings, including (but not limited to):

• Case and CA Owner information

• Root stores applied to (Apple, Mozilla, Google Chrome, Microsoft)

• CA-provided value statements and lifecycle information (per root program)

• Root certificate and hierarchy details

• Certificate metadata (fingerprints, validity, key information)

• CRL and revocation information

• Intended use cases and test websites (if applicable)

• Most recent audit statements and supporting documentation

• In effect non-audit documents (i.e., policy documentation)

• Root-program-specific application status and constraints

This format allows reviewers to see the same data root programs rely on, organized in a consistent and navigable way, without the risk of omissions or transcription errors.

Why this change is being made

• Reduces duplication and manual copying of CCADB data

• Improves consistency across root inclusion announcements

• Ensures community reviewers are always looking at the most current information

• Makes announcements easier to read while preserving transparency

What is not changing

• The 6-week public comment period remains unchanged

• Community review and discussion remain a critical part of the root inclusion process

• All information required for meaningful review continues to be publicly available

How you can help

1. Are there additional, publicly available disclosures or other information that should be included in future root inclusion public discussion announcements? Some examples are: (1) more information about CA ownership and control structures, and (2) clearer context about a CA owner’s intended scope or community served. See e.g., this past discussion and also Mozilla’s Root Inclusion Considerations. 

2. Is there any information that we provide today during the root inclusion process that does not materially contribute to the community’s understanding of a root inclusion request, or that may be redundant with other sources, and that could reasonably be removed or streamlined to improve clarity and focus in public discussion announcements?

Suggestions submitted over the next two weeks (through 2/20) will be greatly appreciated. If you have questions about the new report format or encounter any issues accessing the public views, please let us know.

Thank you for your continued participation and feedback.

Best regards,
Ben Wilson
On behalf of the CCADB Steering Committee

[Aaron Gable]

Just one question: archival of old emails is largely a solved problem, but archival of old web pages is not (despite the best efforts of The Internet Archive). Are these printable case reports guaranteed to be static even after the root inclusion request has been closed? Are these printable case reports going to serve as an effective and resilient archive for someone twenty years from now curious as to why a particular long-lived root was added to their browser's trust store?

I wonder if it would be possible to (for example) attach a PDF of the printable case report to the email, for historical purposes.

Thanks,

Aaron

--
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 public+un...@ccadb.org.
To view this discussion visit https://groups.google.com/a/ccadb.org/d/msgid/public/CA%2B1gtabh9uAHuO4bwD8TGPUt0agibnrOio-rqPpcvaL5Kijzpw%40mail.gmail.com.

[Ben Wilson]

Hi Aaron,

Thanks for raising this, and we agree with you about the problems with linking to a dynamically generated web page. It is highly unlikely that the information in printable CCADB case reports will remain static.

Based on your suggestion, we will attach a PDF snapshot of the printable case report to the announcement email when opening the 6-week discussion period, which will preserve the record information as it existed at the start of the discussion. We'll still include the link to the live CCADB report for convenience and as an ongoing reference. We'll also include some caveat language in the announcement email regarding the two options.

Thanks again for your suggestion and for helping improve our processes.

Best regards,
Ben

[Cynthia Revström]

Hi,

This update sounds good to me. I had the same concern as Aaron but attaching a PDF seems like an adequate solution.

-Cynthia 

To view this discussion visit https://groups.google.com/a/ccadb.org/d/msgid/public/a0eb2703-1200-4225-8c62-a7b90f5ac591n%40ccadb.org.