Summary

  • SC101 rewrites how a certificate authority derives an Authorization Domain Name, or ADN, from the fully qualified domain name requested for a publicly trusted TLS certificate.
  • The ballot describes a dangerous reading of the former definition: prune labels first and then follow a CNAME, potentially allowing the operator of an alias target to validate names it does not control. The new order selects the validation method first and makes CNAME following precede pruning when both operations are allowed.
  • TLS Baseline Requirements v2.2.9 took effect on 6 August 2026, but its own §3.2.2.4 permits a CA to follow either that section or the corresponding v2.2.7 section until 15 November. Adoption therefore did not create one operational rule overnight.
  • A useful transition record binds the requested name, validation method, applicable rulebook, observed CNAME chain, prune operations, final ADN, validation evidence, CP/CPS version and implementation release to the issuance.

The current document contains a deliberate legacy route

Policy transitions are often described as if a new document replaces an old one at midnight. That was not the transition adopted here. The current TLS Baseline Requirements are version 2.2.9, dated 6 August 2026. Their revisions table attributes the change to SC101, “Clarify Authorization Domain Names.” Their relevant-dates table marks 15 November as the compliance date for the new derivation requirement.

The decisive sentence appears inside §3.2.2.4. Before that date, a certificate authority may comply with the current section or with §3.2.2.4 of version 2.2.7. From 15 November onward, it must use the current section. The transition is not an informal grace period inferred from enforcement silence. It is a choice written into the adopted rulebook.

That distinction matters. Suppose a CA issues a certificate on 30 September and its record says only “compliant with the current Baseline Requirements.” The statement sounds precise because v2.2.9 was current on that date. It does not answer the operational question. The CA may have used the new algorithm, or it may have validly exercised the incorporated v2.2.7 option. Both can be compliant; they are not the same derivation.

The institutional event was unusually consensual. The SC0101v2 ballot record reports yes votes from all 27 participating certificate issuers and all four participating certificate consumers—Apple, Google, Microsoft and Mozilla—with no no votes or abstentions. It says the applicable thresholds were met and records a quorum of 17. Discussion ran from 12 to 19 June, voting from 23 to 30 June, and the intellectual-property review from 7 July to 6 August.

Those facts establish adoption. They do not establish that 31 independently operated issuance systems changed their code, tests, configuration, documentation and audit evidence on the same day. A vote records normative agreement. Deployment has to be observed somewhere else.

The name being validated is not always the name on the request

An applicant asks for a certificate containing one or more fully qualified domain names. A CA must verify control under an approved validation method. The name at which that proof is performed is the Authorization Domain Name. Sometimes the ADN is identical to the applied-for name. Sometimes the permitted algorithm reaches a related name after following DNS aliases or removing left-most labels.

That indirection is useful. A domain owner should not have to perform wholly unrelated proofs for every host when the approved method permits a broader authorization boundary. It is also a security boundary: expand the derivation too far and the proof can move from a name the applicant controls to one controlled by a service provider or an unrelated operator.

SC101's ballot explanation says the previous ADN definition combined description with normative instructions. It was unclear whether its operations could be used exclusively, sequentially, repeatedly or in some other combination. The ballot identifies one severe interpretation. A CA could first remove labels from the left side of the requested FQDN and then follow one or more CNAME records.

The ballot uses a simple relationship to show why order changes authority. A CNAME from example.com to example.org lets traffic or DNS resolution move toward example.org. It does not give the operator of example.org control over blog.example.com. If the algorithm prunes blog first, then follows the alias, a party able to demonstrate control over the target—such as a CDN operator—could appear to satisfy validation for a customer subdomain it never controlled.

This is a description of an unsafe interpretation, not a report that a named CDN or CA exploited it. No such claim is needed. The governance problem exists whenever a normative definition can support materially different authorization boundaries.

SC101 turns an elastic definition into an ordered procedure

The revised section does not merely replace one definition with a longer definition. It separates the decisions and gives them an order.

First, the CA begins with the applied-for FQDN and selects the validation method. That choice constrains what transformation is available. Only specified methods may use the CNAME step; only specified methods may use the prune step. A method that proves control at an underscore-prefixed validation name, for example, does not automatically acquire the same alias freedom as a method operating at the name itself.

Second, when both transformations are permitted and used, the CA follows the CNAME chain before it removes left-most labels. That sequence preserves the difference between control of an alias target and control of every subdomain under the alias owner. Pruning cannot be used first to enlarge what the later alias appears to authorize.

Third, the resulting name becomes the ADN. The selected validation method demonstrates control of that ADN, which may or may not be the name originally requested. The current text also consolidates method suitability in a table rather than scattering the authorization consequences across definitions and method prose.

This account is explanatory. Engineers must implement the full normative section and its method table, not an article's six-line paraphrase. But the order is the governance innovation: method, eligibility, CNAME, prune, ADN, proof. An issuance system should be able to expose those states without reconstructing them from a final success flag.

The change followed an immutable source history. The ballot links a specific GitHub comparison, and the Forum's documents page preserves the current and previous requirements. The 18 June working-group minutes record why v2 added a separate effective date for another affected provision. Together these records show how the normative text was made. They still cannot tell an auditor which branch one issuance engine executed.

The receipt should identify the rulebook, not merely the outcome

The ordinary validation log tends to favor success: method completed, challenge matched, certificate issued. A transition log must preserve the path. The minimum useful receipt is:

issuance time + applied-for FQDN + selected validation method + BR version/section + CNAME observations and chain + ordered prune operations + selected ADN + validation evidence and time + CP/CPS version + implementation/configuration release + test or audit reference + exceptions

Each field closes a different ambiguity.

The issuance time resolves which transition choices were legally available. The applied-for FQDN and final ADN show whether authorization moved. The validation method determines which transformations were eligible. The rulebook field distinguishes the v2.2.7 route from the v2.2.9 route. The CNAME observations preserve a DNS state that may change minutes later. The prune record makes operation order inspectable. Evidence identity and time show what proof was actually used rather than what could be fetched now. CP/CPS and implementation versions separate declared practice from deployed code.

Test and audit references show which control examined the behavior.

The fields should be bound to a durable issuance or certificate identifier. Where the CA's architecture permits, hashes can make later substitution visible. Sensitive challenge material need not be disclosed publicly; access controls and retention rules can protect it. The point is not maximal public logging. It is that an authorized reviewer can reproduce the path without guessing which version the phrase “current policy” once meant.

This receipt is an analytical proposal, not a hidden SC101 requirement. The Baseline Requirements already contain extensive logging, CP/CPS and audit obligations, but the Article does not claim that they mandate this exact tuple. It asks what evidence is necessary to make the two-rulebook choice intelligible.

CP/CPS text is necessary and still not an execution trace

The Baseline Requirements require CAs to give public effect to the requirements through their certificate policies and certification practice statements and to review those materials. RFC 3647 supplies the familiar framework for such disclosures. A timely CP/CPS update can say when a CA intends to adopt the new derivation procedure, what system is affected and how exceptions are governed.

That declaration matters, but it is not a per-issuance trace. A document may be updated before the last production node is deployed. Code may be deployed before the document is published. A fleet may operate in a staged rollout. An emergency rollback may restore an older implementation that remains permitted during the window. Auditors may sample across all of these states.

A strong evidence chain joins, rather than substitutes, three records: the published policy, the deployed implementation, and the issuance-specific path. If they disagree, the disagreement is a finding to explain. If only the policy survives, investigators can know what was intended but not which branch the system executed.

Forum adoption and relying-party enforcement are separate records

The Baseline Requirements introduce themselves as necessary but insufficient conditions for publicly trusted TLS certificates. They also say the requirements are not mandatory for CAs unless and until relying-party Application Software Suppliers adopt and enforce them. That sentence prevents an easy category error: the Forum writes a common baseline, while certificate consumers decide what their own root stores accept and how they enforce policy.

Mozilla's Root Store Policy is a public example. It incorporates common requirements but retains controlling and potentially stricter Mozilla provisions. Apple's Root Program Policy likewise maintains a current program policy around incorporated external standards. These references establish layered authority; they do not turn this Article into an assessment of either program.

Four propositions can therefore be true at once: SC101 was unanimously adopted by those who voted; a CA could validly remain on the incorporated v2.2.7 section before the deadline; a CA's own CP/CPS could announce a different earlier cutover; and a root program could apply its own expectations. “The ballot passed” cannot answer all four.

The adjacent production question—how a browser can end trust without winning a Forum vote—deserves its own analysis. Here the narrower question comes first: can the CA prove which permitted ADN derivation governed a particular certificate? Root-program authority does not repair a missing issuance trace after the fact.

Uncertainty is concentrated in implementations, not the deadline

The public normative state is clear enough. Version 2.2.9 is current; its transition clause names the alternative; 15 November is the cutover date. What remains uncertain from public documents is how each CA maps that choice into code, configuration, policy text, logs, test fixtures and auditor samples.

It would be wrong to label a CA noncompliant merely because a public implementation notice is absent. It would also be wrong to infer the new algorithm from a generic claim of current-BR compliance. Evidence has to be obtained at the appropriate layer. Until then, the honest status is “rulebook not demonstrated,” not “legacy” or “updated.”

Sources