Summary

  • SC100 received 22 yes votes from participating certificate issuers and three yes votes from certificate consumers, with no no votes or abstentions. Its IPR review is scheduled to end on 5 September 2026; it was not yet part of the current TLS Baseline Requirements at this Article's 31 August cutoff.
  • The draft consolidates existing DNSSEC rules. It requires validation at the Primary Network Perspective for relevant domain-control and CAA queries, subject to a narrow email-method exception, while DNSSEC at Remote Network Perspectives remains optional.
  • Multi-Perspective Issuance Corroboration, or MPIC, is independent of that asymmetry. Remote observations corroborate the Primary determination; a remote can count in the MPIC process without the rules making DNSSEC mandatory at that remote.
  • Because the draft excludes the full DNS lookup set from specified logging and self-audit scopes yet requires sufficient retained proof, a useful record must join a time-bounded resolver-control receipt to an issuance receipt that names the Primary perspective and records DNSSEC separately for each remote.

Two documents can say 2.2.9 without having the same status

The official SC100 page records an unusually clean vote. Twenty-two participating certificate issuers voted yes. Apple, Cisco Systems and Mozilla supplied the three yes votes from certificate consumers. There were no no votes and no abstentions, and the recorded quorum of 15 was met.

That is a vote result, not the end of the adoption chain. The same page says the intellectual-property review began at 19:00 UTC on 6 August and is scheduled to end at 19:00 UTC on 5 September. At the research cutoff, members still had time to submit exclusion notices. The 13 August working-group minutes likewise described SC100 as having recently entered IPR review.

The status is easy to misread because the changes-accepted attachment is headed version 2.2.9 and dated 6 August. The current requirements page also identifies the released TLS Baseline Requirements as version 2.2.9, dated 6 August. Yet the current revision table ends with SC101. SC100 is not listed as a released revision. The Forum's documents index and the ballot's review notice provide the necessary distinction: one 2.2.9 is the current Final Guideline; the other is a complete Draft Maintenance Guideline generated for review.

This is not clerical trivia. A compliance statement must identify the document state, not merely the number printed in its header. “Version 2.2.9” cannot by itself tell a reviewer whether the speaker means the current release, the SC100 accepted draft, or a later release that may incorporate it.

The ballot supplies another restraint. It says SC100 has no effective date because its purpose is clarification and consolidation, with no intention to modify the existing requirements. The Article therefore does not announce a new control. It asks what evidence would make the clarified control verifiable.

The mandatory act belongs to a role, not to the word “DNSSEC”

The underlying duty came from SC085v2. From 15 March 2026, the relevant domain-control and CAA queries performed at the Primary Network Perspective must undergo DNSSEC validation when the chain is present. Current 2.2.9 carries that requirement in several places.

SC100 would consolidate the material in a proposed §4.2.2.2. Its clean draft PDF first describes the resolver used by the Primary Network Perspective. That resolver must perform validation under RFC 4035 §5, support NSEC3 and SHA-2, and handle the security concerns identified in RFC 6840 §4.

The next subsections allocate behavior. The Primary Network Perspective must perform DNSSEC validation on all DNS queries associated with domain authorization or control and CAA processing. The remaining email-based validation methods have a partial exception: CNAME, CAA and TXT queries used to obtain the Authorization Domain Name remain mandatory, while other queries use SHOULD language. For the other methods and CAA, local policy cannot disable the validation. A DNSSEC error observed at the Primary perspective—SERVFAIL is the example—cannot be treated as permission to issue, within the stated exception boundary.

The remote rule is different. Remote Network Perspectives used for MPIC may perform DNSSEC validation back to the IANA root trust anchor. MAY is not MUST, but neither is it MUST NOT. The draft does not declare remote validation defective, unnecessary or forbidden. It places the minimum mandatory control at the Primary role while allowing CAs to add remote cryptographic validation.

That role assignment is the real evidentiary boundary. A database row containing dnssec_status=secure proves little if it does not identify the network perspective that generated the state. A conforming remote result cannot substitute for an absent Primary result merely because both used the same protocol. Equally, a Primary result cannot be copied across remotes and presented as if each perspective made an independent DNSSEC decision.

MPIC adds independent observations; it does not multiply the DNSSEC MUST

The SC067v3 ballot introduced MPIC to make equally specific BGP attacks against domain validation harder. Current §3.2.2.9 describes the process as corroborating the Primary Network Perspective's domain-validation and CAA determinations from remote Network Perspectives before certificate issuance.

The two controls protect different edges.

DNSSEC asks whether a resolver can validate the cryptographic chain for DNS data, including authenticated denial of existence, under the protocol's trust model. RFC 4035 gives resolvers the familiar Secure, Insecure, Bogus and Indeterminate categories. Those labels describe a validation state; they do not identify the CA's issuance method, observation role or final decision.

MPIC asks whether sufficiently distinct remote observations corroborate what the Primary perspective saw. The SC100 draft reproduces the phased implementation schedule: since 15 June 2026, applicable validation uses at least four remote perspectives, must satisfy the quorum table and must obtain corroboration across at least two RIR service regions. From 15 December, the minimum becomes five. Those are remote-observation counts, not mandatory DNSSEC-validator counts.

A remote perspective can therefore report a corroborating challenge or CAA outcome without the Baseline Requirements obliging that remote to validate DNSSEC. A CA can choose to validate DNSSEC there and record a richer state. Both cases can fit the draft. The evidence must say which occurred.

Collapsing the controls produces two bad inferences. One is that a valid MPIC quorum proves that all observations were DNSSEC validated. The other is that optional remote DNSSEC makes the MPIC quorum hollow. Neither follows from the text. Geographic and network diversity do not become cryptographic validation, and cryptographic validation does not become geographic diversity.

The Forum deliberately left the logging implementation open

The evidence issue did not arrive by accident. SC096 carved DNSSEC verification out of broad DCV and CAA logging. Its summary said resolvers were not built for extensive logging and pointed to change-management records as a way to show that appropriate controls were in effect.

SC100's proposed §4.2.2.2.7 preserves an exclusion. The full set of DNS lookup information related to DNSSEC validation would remain outside the scope of §8.7 self-audits and §5.4.1 logging. It then adds the sentence that matters: notwithstanding those exclusions, the CA must retain information sufficient to verify compliance with the rest of the DNSSEC section.

The 16 July minutes record the design decision. The remaining issue was whether to prescribe specific logging. Participants favored sufficient evidence while preserving flexibility in how it was kept. Revised language restarted discussion; the 30 July minutes later recorded no additional comments before voting.

That is a reasonable standards choice. A normative document should not force every CA to deploy the same resolver or storage architecture. But flexibility shifts work to the evidence designer. What is the smallest record that proves a role-specific control without recreating the full DNS transcript that the draft deliberately excludes?

One receipt describes the control; another describes the issuance

The answer should not be “log everything.” It should be a bounded join between two receipts.

The control receipt describes the resolver and Primary-perspective configuration during a defined interval. At minimum it should preserve:

control receipt ID + Primary perspective ID + resolver/service ID + software/build + configuration or policy hash + trust-anchor set/version + RFC 4035 validation state + NSEC3/SHA-2/RFC 6840 capability references + local-policy exception state + test-run IDs + valid-from/valid-to + approved change record

This receipt can use hashes and controlled references rather than exposing secrets or a complete configuration. Its purpose is to turn the generic claim “DNSSEC was enabled” into a time-bounded, attributable control state. Change-management evidence is valuable here. It proves what operators approved and what tests were associated with a resolver release.

The issuance receipt describes what happened for one validation attempt. It should bind:

attempt and certificate/precertificate ID + request and decision time + requested name and validation scope + validation method + CAA scope + governing BR/draft version + Primary perspective ID + resolver/control-receipt ID + query families + DNSSEC state + error/fail-closed decision + remote perspective IDs + per-remote DNSSEC-performed flag and state + RIR-region references + MPIC observations/quorum + retry lineage + immutable record hash

The most important fields are not the longest ones. They are Primary perspective ID and the per-remote DNSSEC performed flag. Without the first, a secure state has no normative role. Without the second, silence is ambiguous: it can mean optional validation was not performed, the result was lost, or the data model never represented the choice.

When a remote did not perform DNSSEC, the record should say so neutrally: not performed under a permitted optional state. It should not manufacture Insecure, because Insecure has a protocol meaning. When a remote did validate, its result belongs to that remote and its resolver. The Primary result must never be copied into remote rows for convenience.

The issuance receipt need not contain full packets, every resource record or a complete resolver debug trace. It needs enough to reconstruct the proposition under review: the required Primary role used a conforming control on the relevant query set; a validation error was not converted into permission to issue; and the separate MPIC process met its quorum.

This two-receipt design is Daniel Kade's proposal. SC100 does not enumerate these fields, and the Article does not attribute them to DigiCert, the ballot endorsers, the voters, an auditor or the RFC Editor. The Forum chose a sufficiency standard. The receipt is one way to make sufficiency testable.

A success flag cannot join policy, execution and decision

Consider four statements:

  1. The CA's CP/CPS says DNSSEC validation is enabled.
  2. A resolver configuration passed a conformance test.
  3. A validation attempt returned Secure.
  4. A certificate was issued after an MPIC quorum.

All four may be true and still fail to show that the required Primary perspective used the tested configuration for the relevant queries on that attempt. The missing information is the join.

A CP/CPS is a declaration of practice, not a packet-level observation. A test proves behavior under its test conditions, not every later invocation. Secure describes a DNSSEC state, not whether the result came from the Primary role. A certificate proves an issuance event, not the path by which the CA reached it. An MPIC quorum records corroboration, not mandatory DNSSEC at each member.

The governance error is familiar: the record of a rule is mistaken for the act the rule assigns. SC100 makes the assigned role clearer. Evidence should follow that role all the way from configured capability to issuance decision.

What the public record cannot establish

The public sources do not show whether any named CA has already implemented the SC100 draft, how its internal resolvers are organized, or what its issuance logs retain. The unanimous vote does not prove deployment. The absence of public implementation detail does not prove noncompliance. The article identifies no misissuance, poisoning event or concealed log.

The sources also cannot predict whether an exclusion notice will be filed before 5 September, whether the accepted text will change, or which version number a later release will carry. The correct status remains: vote passed, review open, current release unchanged.

Sources