Upcoming F2F: Proposed Discussion Outline for Section 7 & Profile Modernization Discussion

[Ryan Dickson]

Hi everyone,

During last week’s SCWG teleconference, we proposed a few discussion ideas for the F2F. For those not on the call, they are summarized below.

1. Section 7 Cleanup and Modernizing Certificate Profile Expectations: Removing unnecessary complexity (including revisiting the legacy framing around “technically constrained” Subordinate CAs) while establishing clearer, more standardized expectations for how certificate profiles are defined and disclosed.

2. Profile-Specific Linting Expectations: Moving beyond checking against generic BR minimums toward validating against a CA Owner’s explicitly stated commitments and specific profiles (which requires well-defined profiles as a prerequisite).

3. Aligning the BRs with “Dedicated” Hierarchy Expectations: Defining clear, TLS-specific ICA profiles and establishing a future timeline where certificates chaining to those ICAs must lead to roots that exclusively serve TLS use cases (following up on our F2F 66 presentation).

4. Domain Transparency and Issuance Information: Circling back to the SC-093 discussions regarding DCV methods in certificates by exploring new issuance metadata disclosure concepts that could increase transparency and improve security without bloating certificate sizes.

Based on initial feedback during the call, idea #1 generated the most interest for a dedicated F2F session. In practice, we suspect a comprehensive discussion on Section 7 will naturally intersect with and enable ideas #2 (linting) and #3 (dedicated hierarchies). Idea #1 might also intersect nicely with a presentation from IdenTrust (“Leveraging common in-house tools and AI to automate policy gap analysis with CA/B ballots”).

To help ensure a productive session, we volunteered to draft and share a tentative discussion outline with the group (below).

Tentative discussion outline (feedback welcome)

Note: Depending on the degree of community participation (encouraged!), these timelines could be wildly inaccurate.

• [2 minutes] Establish “ground rules” and expectations.

• [10 minutes] Establish context and background

• Why explicit, unambiguous profiles are essential

• A brief look at how and why profile requirements in the TLS BRs have evolved over time

• [Up to 15 minutes] Discuss challenges with the current state

• (Community discussion, but a few conversation starters are below)

• Requirements are often scattered across prose and tables, sometimes across several different sections.

• Optionality -> Complexity. 

• English is hard, even for native speakers.

• Humans make mistakes.

• [Up to 30 minutes] Discuss near-term ideas to address those stated challenges

• (Community discussion, but a few conversation starters are below)

• Promote Simplicity:

• Transition away from “tabular inheritance.”

• Remove “unused” options (e.g., sunsetting IV certificate profiles)

• Sunset the concept of “Technically-Constrained” 

• Sunset non-TLS profiles from the BRs (e.g., 7.1.2.3 - Technically-Constrained Non-TLS Subordinate CA Certificate Profile).

• Clarify expectations:

• Establish sharper expectations for actual (not illustrative) profile disclosure - where profiles represent what is made possible by the CA’s actual configuration, and not the floor of what the BRs allow.

• Establish sharper expectations for exhaustive profile disclosures (and, how to express which CAs support those profiles to avoid redundancy). 

• Improve Linting

• Establish stronger linting expectations where CA Owners treat disclosed profiles as “default deny”, and where they lint their specific stated practices, rather than only the floor that the BRs allow (or a subset).

Note: For each potential solution, we should consider the challenge we’re addressing, prerequisite tasks, lead time, and cascading impact.

• [Up to 10 minutes] Summarize discussion, commit to next steps, and get volunteers to carry the work forward.

• [Up to 30 minutes] - “Blue Sky” thinking

• (Community discussion, but a few conversation starters are below)

• Machine readable (and exportable) profile formats

• Standardize formats and schemas (e.g., JSON, YAML) for profile declarations.

• Balance machine readability with human and auditor accessibility.

• Ensure machine-readable disclosures accurately reflect CA issuance configurations rather than becoming another static document to maintain.

• Profiles instead being a disclosed set of lints. 

• [5 minutes] Summarize discussion and commit to next steps. 

Looking forward to hearing people's thoughts!

Thank you,

Ryan