Summary

  • Draft pull request 679 would add ML-DSA-44, ML-DSA-65 and ML-DSA-87 to the TLS Baseline Requirements for Subscriber and CA certificates, CRLs and OCSP responses. It also proposes “pure” key-and-signature pairings, with a status-object carve-out.
  • The proposal says it would not compel root-store trust or alter the signatures used for Certificate Transparency timestamps. Its stated demand includes SDK clients, embedded and IoT systems, middleware and applications relying on system trust stores.
  • The SCWG charter authorises work on TLS server certificates for Internet-accessible servers. Yet its voting Certificate Consumer is defined through software for browsing the Web securely, and its voting Certificate Issuer through certificates accepted by such a browser.
  • The charter expressly excludes one narrower class—internal-only enterprise PKI whose root is not distributed by a Certificate Consumer. The public text therefore exposes a genuine interpretive boundary; it does not prove that every non-browser case is outside scope.
  • SC-106 was still an open Draft PR at the 2 September cutoff and was absent from the official ballot-status page. Public comments and the 2025 Tokyo minutes show disagreement, not a Working Group decision.
  • A mandate receipt should identify the intended relying parties, controlling charter clause, voting constituency, common invariant, root-store and CT boundaries, implementation evidence, alternative venue and review trigger before profile permission is mistaken for universal representation or deployment.

Two constituencies appear in the same proposal

The most revealing line in SC-106 is not an object identifier. It is the list of users offered as the reason for acting.

Pull request 679 says many relying parties have no practical route to post-quantum authentication through existing X.509 public trust. It names SDK-based service clients, embedded and IoT systems, enterprise middleware, and applications that validate against trust stores managed by operating-system vendors. Those are concrete constituencies. They are not merely “the ecosystem,” and several are not browsers.

The SCWG charter uses a different centre of gravity. A voting Certificate Consumer must produce software intended for the general public to browse the Web securely. A voting Certificate Issuer must issue certificates for openly accessible Web servers that are treated as valid by a browser created by a Certificate Consumer member. The ballot rule then requires support across the issuer and consumer voting classes.

Both texts can describe real needs. The governance question begins when they are treated as if they automatically describe the same principal.

The draft may be useful to a device fleet, a server-to-server client or an enterprise application. The browser-defined consumer class may have deep expertise in public trust, certificate processing and migration risk. Expertise is valuable evidence. Under the mandate discipline in Lu Heng’s work, however, expertise and participation do not by themselves identify who authorised a decision for an affected party.

A standards body should be able to state whether it is establishing a Web minimum with collateral non-Web utility, a shared public-trust profile for several relying-party classes, or a profile principally commissioned by users outside its voting definition.

SC-106 does not yet provide that institutional receipt.

What the frozen draft actually changes

The technical proposal is specific. At the frozen head commit eefc670…, the Baseline Requirements would recognise the three ML-DSA parameter sets standardised in FIPS 204: ML-DSA-44, ML-DSA-65 and ML-DSA-87. It would add encoding validation, Subscriber key-usage constraints and exact algorithm identifiers. HashML-DSA would be prohibited; only the “pure” ML-DSA form would be permitted.

The draft then couples the key being certified and the signature over the certificate in both directions. An ML-DSA subject public key could not appear unless the certificate signature were also ML-DSA. An ML-DSA certificate signature could not certify a classical subject key. The second rule would not apply to a CRL or an OCSP response because those objects do not certify a public key.

The preamble draws two important limits around those additions. Passing the proposal would not require a root-store operator to accept an ML-DSA hierarchy. It would not replace the algorithm used by a Certificate Transparency log to sign an SCT. The draft is therefore a permission profile, not a trust decision and not a CT deployment order.

Those limits are signs of good institutional hygiene. They also make the scope question sharper. If root programmes retain the decisive trust choice and CT operators retain their own signature and capacity choices, what precise common obstruction is the SCWG removing for each named non-Web client? Is the obstruction a CA audit rule, a root-policy rule, certificate tooling, path construction, a trust-store update, or simply the absence of a common encoding profile? Different answers can point to different owners.

No source reviewed for this article supplies a census of the named relying parties, a list of deployments blocked by the present BR text, or a statement from those constituencies authorising the SCWG to choose their migration profile. That absence does not refute the need. It defines the evidence still missing.

Draft is a procedural state, not a nickname for a ballot

The repository title calls the proposal SC-106, and the pull-request body repeatedly calls it a ballot. At the research cutoff, the public repository still marked it Draft. It contained one commit, no formal review and an open discussion thread. The official SCWG ballot page did not list SC-106 under Voting, IPR Review, Discussion, Draft or the historical ballot list.

The bounded conclusion is simple: SC-106 was a draft pull request on 2 September 2026. The evidence does not establish a formal discussion window, endorsers, a voting period, a result, IPR review, a Final Maintenance Guideline or an effective date.

This is more than terminology. A repository author can propose text. A working group can place a qualified text into its ballot process. Voting classes can adopt or reject it. The IPR process can expose exclusions. A final guideline can make a requirement operative on a stated date. Root programmes, CAs, CT systems and relying parties can then implement, narrow or decline it within their respective authority. Calling every early state “the ballot” compresses all of those decisions into the first document.

The immutable comparison remains useful even if the text changes tomorrow. It proves exactly what one draft proposed. It cannot prove what the Working Group has decided.

The charter is broader and narrower at once

A clean scope argument cannot quote only the word “browser.” Section 1 of the SCWG charter authorises requirements and acceptable practices for issuing and managing TLS server certificates used to authenticate servers accessible through the Internet. It also authorises updates for emerging online-security threats and activities ancillary to that work. That language is not limited to one browser implementation.

Nor can the opposite argument quote only “servers accessible through the Internet.” Membership defines who may cast the consumer-class vote. That definition expressly anchors eligibility in software for secure Web browsing. Issuer eligibility is also tested through acceptance by a browser made by a consumer member. The procedure’s decision constituency is therefore narrower than the universe of software that can validate an X.509 path.

The out-of-scope clause adds another boundary. It excludes certificates issued by enterprises operating their own PKI for internal purposes only when the root is not distributed by any Certificate Consumer. It also excludes several primary uses such as code signing and S/MIME. This does not say that every system-trust-store client or every non-browser TLS use is forbidden. It does show that the charter knows how to exclude use classes expressly.

The honest reading is tension, not a verdict. The activity clause may be read broadly enough to cover a common Internet TLS profile with non-browser beneficiaries. The voting definitions may be read as evidence that the body’s represented consumer interest is Web browsing. The internal-PKI exclusion may leave some public or system-root non-browser uses inside while excluding others. The word “ancillary” may matter, but it should not become an unlimited container for work whose primary justification lies elsewhere.

A public interpretation should name which clause does the work and who owns that interpretation. Silence would let the technical text settle a constitutional question indirectly.

The Forum had this argument before ML-DSA

The mismatch did not arrive with quantum-resistant signatures. Minutes from the SCWG’s March 2025 meeting in Tokyo record a long discussion titled “Clarify scope of TLS Baseline Requirements.” Participants debated browser versus non-browser uses, operating-system trust stores, private and public PKI, server-to-server applications and whether a separate working group was needed.

The minutes preserve opposing practical concerns. Some participants argued that browser root programmes supply the operational reality to which the BRs should be tethered. Others warned that operating systems and applications use the same roots, that non-browser users lack an alternative, and that browser-specific requirements can fragment those uses. The recorded summary identified two perspectives: the BRs as the only practical home for broader use cases, or an increasingly browser-specific rule set that should be separated or clarified.

Those minutes are not a charter amendment. They record discussion, not consensus. Their significance is narrower and stronger: SC-106 has landed on a documented fault line that the Working Group already knew existed.

The August 2026 pull-request comments reproduce that line. One contributor described the focused cases as “non WebPKI.” Ben Wilson argued that path assurance depends on the path the relying party constructs and accepts, leaving room for transition paths alongside an all-post-quantum path. A later Chrome comment distinguished the two directions of mixed chains, questioned whether the non-browser focus matched the charter and suggested another CA/B Forum working group.

Each is an attributable view. None is the collective position. The article does not turn a GitHub reaction count into a vote, a vendor view into a veto or a meeting minute into constitutional law.

Path purity is also a map of decision rights

The pure-chain debate appears cryptographic, but it exposes the governance surface.

The draft’s rationale says a classical signature anywhere on a presented chain leaves that chain with classical assurance. That statement can be true for the chain under examination without answering whether the profile should prohibit every mixed construction. Ben Wilson’s comment makes the adjacent point: a relying party may reject classical alternatives and validate a separate all-post-quantum path; the existence of another path does not alter the signatures in the accepted path.

RFC 5280 helps keep the layers apart. A prospective certification path and trust-anchor information are inputs to validation. Selection of a trust anchor is a matter of policy, and different paths need not begin with the same anchor. A Baseline Requirements profile can constrain what a CA issues. It does not itself choose which path a relying party constructs or which anchor a local trust policy accepts.

That separation does not prove the mixed-chain restrictions should be removed. A classical CA signing a post-quantum Subscriber key can create different CT capacity and security consequences from a post-quantum CA signing a classical key for transition. A common profile may legitimately forbid a construction to protect a shared invariant.

But the invariant must be stated. Is it “any certificate carrying ML-DSA must be labelable as end-to-end post-quantum under every possible path”? Is it “existing Web CT logs must not inherit larger Subscriber objects under classical roots”? Is it “a browser’s accepted path must resist downgrade”? These are not identical rules.

When one restriction tries to solve path assurance, CT admission, root signalling, legacy compatibility and non-browser migration at once, it risks placing local decisions into a common layer before their common necessity has been demonstrated.

Running implementations show plural routes, not one winner

Chrome’s public roadmap illustrates one Web-specific route. It describes staged post-quantum HTTPS authentication, certificate negotiation, paired classical and post-quantum credentials, downgrade protection and a very long path to removing classical options. Its preferred public-Web architecture uses Merkle Tree Certificates rather than traditional X.509 ML-DSA certificates.

The Chrome Quantum-resistant Root Program makes the separation observable. Chrome says traditional ML-DSA X.509 certificates are supported in private PKI hierarchies from Chrome 150. Separately, it offers a test-only MTC root store whose cosigners are explicitly not trusted for production. The testing programme uses its own algorithms, log and mirroring requirements and future production path.

This is not evidence that Chrome’s design should govern every SDK or embedded client. It is evidence that a standards label is not the only route to experimentation. A browser can test one certificate architecture, support another in private PKI and keep production trust separate. Other root programmes and system trust stores can make different, attributable decisions.

That is close to the minimum-specification discipline in Lu Heng’s work: place only the necessary shared invariants in the common layer, preserve local validation and make later adoption observable in running systems. Applied carefully, the doctrine does not say “never standardise.” It asks which facts must be common before interoperability is possible and which choices can remain in named compatibility sets.

FIPS 204 answers one common question: what ML-DSA is and how its three parameter sets operate. The certificate profile answers encoding and issuance questions. A root policy answers which hierarchies are trusted. CT policy answers which objects are admitted and how transparency is proved. A relying party chooses a path under local policy. Deployment evidence shows what actually runs. None of those answers can impersonate all the others.

A mandate receipt before a common profile

The missing artifact need not be a constitutional essay. One public table could do the work.

Proposal identity. Record the immutable base, proposed commit, status, proposer, endorsers when formal, discussion and voting windows, vote receipt, IPR state, final version and effective date. Draft edits must remain distinguishable from authorised text.

Intended relying parties. Name browsers, operating-system validators, SDKs, embedded clients, IoT devices, enterprise middleware and private or public PKI separately. Do not use “certificate consumers” as a bag that hides which class is meant.

Mandate source. Cite the precise charter clause for each included class, the body empowered to interpret it and any unresolved objection. Record whether the work is a Web minimum with collateral utility, an ancillary profile or a broader multi-constituency standard.

Representation boundary. Identify which named relying parties can vote in the consumer class, which participate only as interested parties or experts, and which have no formal route into the decision. Absence does not create a veto; it prevents a claim of representation.

Shared invariant. State the harm that requires a common rule rather than local profiles. Keep certificate encoding, path strength, downgrade resistance, CT capacity and root admission as separate rows.

Local decision rights. Record that root programmes choose trust, CT programmes choose admission and operational policy, CAs choose whether and how to issue within permitted rules, and relying parties choose accepted paths and anchors. Name any place where the proposal deliberately constrains one of those choices.

Implementation evidence. List test vectors, libraries, certificate sizes, path-building results, CT experiments, root pilots and failure observations by version. A claim that a constituency is blocked should point to a reproducible obstruction.

Venue and review. Compare proceeding in the SCWG, amending or clarifying its charter, creating another Forum working group, or publishing a narrower profile elsewhere. Set a review date and revision trigger so an experimental constraint does not become permanent merely by surviving.

This receipt does not require unanimity. It does not give every SDK vendor a veto. It makes the chain from need to authority and from authority to deployment inspectable.

What cannot be concluded on 2 September

The public evidence does not show that SC-106 is invalid, captured, unnecessary or technically unsound. It does not show that the SCWG has collectively agreed with the scope objection. It does not show that every named non-browser client is outside the charter, or that the Internet-server clause automatically includes all of them.

It also does not show that traditional ML-DSA X.509 certificates will enter a production browser root, that CT can or cannot carry a particular volume, or that either direction of mixed chain will be adopted. The draft itself disclaims power to compel root trust and to change SCT signing. Chrome’s roadmap is a product strategy, not a Forum decision. Public comments are proposals and objections, not settled text.

The distinction matters because this is early enough to repair the record cheaply. Once a profile is adopted, audit criteria, issuance tooling and procurement documents can treat its institutional provenance as settled. A later working group may then inherit the constraint as “the industry standard” even if the original constituency question was never answered.

The profile can be narrow without being weak

The best outcome is not necessarily a larger mandate or a smaller one. It is an explicit one.

If the SCWG determines that Internet-accessible server authentication authorises the profile and that the browser-defined voting classes are the appropriate decision mechanism, it can publish that interpretation and bound the affected non-Web uses. If the profile is mainly for system, SDK and embedded clients whose needs diverge from Web CT and browser agility, a separate working group may give those consumers a clearer seat and allow different constraints. If running pilots can proceed under root-specific policies, the common text can wait while evidence accumulates.

Each path is legitimate only within its own receipt. None should be smuggled in by calling the others implementation detail.

SC-106’s draft already performs one useful act: it separates Forum permission from root-store trust and CT signatures. The next separation should be institutional. Name the relying party. Name the charter authority. Name the decision that remains local. Then let a technical profile be no more—and no less—than the mandate that produced it.

Sources

  1. Lu Heng, “The Multi-Stakeholder Mirage”
  2. Lu Heng, “Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption”
  3. CA/Browser Forum servercert pull request 679, SC-106
  4. Immutable SC-106 comparison
  5. Proposed TLS Baseline Requirements at the frozen head
  6. Server Certificate Working Group Charter
  7. SCWG face-to-face meeting 64 minutes
  8. CA/Browser Forum Bylaws
  9. Server Certificate Working Group ballot status
  10. NIST FIPS 204
  11. RFC 5280, section 6
  12. Chromium, “Post-Quantum HTTPS Authentication Roadmap”
  13. Chrome Quantum-resistant Root Program testing instructions