Summary

  • At the Baseline Requirements commit named by ballot SC-104, a TLS Subscriber Certificate must contain the non-critical Authority Information Access extension. Inside it, however, an id-ad-caIssuers entry is a SHOULD and an id-ad-ocsp entry is a MAY.
  • SC-104 proposes two textual edits: change the extension’s presence from MUST to SHOULD, and make the requirement for at least one AccessDescription conditional on the extension being present. The two method-level rules do not change.
  • The ballot notice placed voting between 27 August and 3 September 2026 at 00:00 UTC. At this article’s 2 September research cutoff, the proposal had no attributable final vote, completed IPR review or published Guideline status.
  • caIssuers supports issuer-certificate discovery for path construction; OCSP points to an online status service. They occupy one ASN.1 container but do different work. A client may also obtain an intermediate from a server, cache or preload rather than an AIA fetch.
  • A credible result therefore needs five joined but separate records: procedural state, profile rule, method rule, issued certificate bytes and relying-party observation. One “AIA compliant” flag cannot prove all five.

The mandatory box with no mandatory service

The current requirement has the shape of a nesting puzzle. In the Subscriber Certificate Extensions table at SC-104’s declared base commit, authorityInformationAccess is a MUST. Section 7.1.2.7.7 then says its AuthorityInfoAccessSyntax must contain one or more AccessDescription values. But the permitted access methods are not both mandatory. id-ad-caIssuers is a SHOULD; id-ad-ocsp is a MAY; any other method is forbidden.

That arrangement is not internally empty. A present extension cannot be an empty shell. Location encoding, uniqueness and ordering rules still apply, and a SHOULD retains real normative weight. Yet the profile does not promise every relying party one particular method. The outer box is mandatory while each named service inside it has a different, weaker presence level.

SC-104 addresses that mismatch narrowly. Its immutable comparison changes MUST to SHOULD in the Subscriber Certificate Extensions table. It adds “If present” to the sentence requiring one or more access descriptions. It does not change the method table. It does not convert caIssuers to MAY, promote OCSP to SHOULD, add a new method, change the permitted URI type or rewrite the rules for CA Certificates and OCSP responder certificates.

Two lines are enough to alter an audit answer. They are not enough to predict an operational result.

SHOULD is a rule, not a blank space

The ordinary-language temptation is to translate SHOULD as optional. RFC 2119 is more demanding. A SHOULD permits valid reasons to depart from the recommendation, but only when the implications are understood and carefully weighed. RFC 8174 makes clear when those capitalised words carry their standards meaning.

If SC-104 eventually becomes operative, a Subscriber Certificate without AIA would no longer breach a MUST presence row. That does not mean omission would become normatively invisible. The issuer would still be departing from a SHOULD. A useful compliance record would preserve the exception reason, the issuance profile that authorised it and the scope of certificates affected. Reducing three states—present by default, absent under a reasoned exception, and casually omitted—to a Boolean “allowed” discards the very discipline that distinguishes SHOULD from MAY.

The same precision is needed inside the extension. An issuer can satisfy the proposed outer recommendation and still make different choices about the methods. It may include caIssuers, OCSP or both, subject to the unchanged table. Saying “AIA is present” therefore does not say which access path exists. Saying “AIA is optional” says even less.

This is where Heng Lu’s minimum-rule discipline becomes useful without being made to endorse a certificate ballot it never discussed. A common rule works best when its state is deterministic and locally verifiable. Adoption and deployment must remain separate from publication. Applied here, that means recording the exact Guideline version and certificate bytes before making any claim about what an issuer did, then recording client behaviour separately before making any claim about what the ecosystem experienced.

One container, two jobs

RFC 5280 describes Authority Information Access as a place to identify information and services about the certificate’s issuer. Its ASN.1 value is a sequence of access descriptions. Two familiar object identifiers then lead in different directions.

id-ad-caIssuers identifies a location from which issuer certificates may be obtained. That can help a relying party select or build a certification path. id-ad-ocsp identifies an online certificate-status protocol service. One concerns finding issuer material; the other concerns obtaining status information. Sharing an extension does not make them substitutes.

The Baseline Requirements themselves preserve that difference. The current Subscriber Certificate table gives caIssuers a SHOULD and OCSP a MAY. Elsewhere, CRL timing and CRL Distribution Point rules can depend on whether a Subscriber Certificate includes an AIA OCSP pointer. Removing the outer extension is therefore not semantically identical to removing a caIssuers URL, and removing a caIssuers URL is not identical to removing an OCSP URL. The observation must name the method.

The distinction also prevents a common narrative jump. A certificate without caIssuers does not, by that fact alone, prove that a client cannot build a chain. A TLS server can supply intermediates. A client may already possess an intermediate in a local store or cache. A vendor may distribute intermediates through another mechanism. Conversely, the mere presence of a URL does not prove that a client will fetch it, that the fetch is enabled, that the resource is reachable or that the returned material leads to a valid path.

The certificate is evidence about encoded pointers. It is not a transcript of the validation run.

Two implementation examples, neither a universal client

Microsoft documents AIA retrieval in Windows as a mechanism that can fetch missing issuer certificates, and it documents administrative controls that can disable that retrieval. That single example already creates several states: product and version, policy configuration, local cache, URL availability, network access and path outcome. “Windows supports AIA” is not a sufficient observation.

Mozilla described another approach in 2020: preloading disclosed intermediate CA certificates into Firefox through Remote Settings. The stated goal included reducing unknown-issuer errors that arise when sites fail to send the correct intermediate chain. A preload can reduce dependence on a live caIssuers fetch in some cases, but it is not proof that every relevant intermediate is always present, every Firefox version behaves identically or server chain configuration no longer matters.

These sources are valuable because they break the imaginary one-client model. They do not establish current market share, universal behaviour or the effect SC-104 will have. A corporate Windows deployment with retrieval disabled, a Firefox installation with a populated intermediate cache, an embedded TLS stack with no network fetching, and a freshly installed application can encounter the same certificate under different conditions. A ballot text cannot collapse those conditions into one forecast.

Nor should server responsibility disappear into the client discussion. A well-configured TLS service supplies an appropriate chain. A client’s ability to recover a missing intermediate is a resilience path, not a general permission to ship an incomplete chain. SC-104 changes a certificate-profile recommendation; it does not rewrite the TLS handshake or prove that server operators may transfer chain delivery to client-side fetching.

A ballot has a lifecycle before it has a result

The public SC-104 notice identifies Ethan Davis of Google Trust Services as proposer and Roman Fischer of SwissSign and Stephen Davidson of DigiCert as endorsers. It names Baseline Requirements version 2.2.9 and links an immutable comparison between the base and proposed commits. The stated discussion period ran from 20 to 27 August 2026 UTC; voting ran from 27 August to 3 September at 00:00 UTC.

Those dates matter because a proposal can be technically legible while its authority remains unsettled. At the 2 September cutoff, the safe statement is that voting was in progress. A repository pull request, a voting notice and even a later successful vote are different states. Under the CA/Browser Forum procedure, a successful ballot must also pass through the applicable intellectual-property review before a Final Maintenance Guideline is published. The operative version and effective dates then need their own record.

This article therefore does not report a result early. If the vote later passes, that does not retroactively make the text operative on 2 September. If the vote fails or changes, the immutable redline remains evidence of what members considered, not what certificates were required to contain.

The procedural receipt should carry the ballot identifier, proposer and endorsers, declared base, proposed commit, discussion window, voting window, eligible-voter denominator, votes, result, IPR state, exclusion notices, final Guideline version and effective date. Each later event appends a state; none silently overwrites the earlier one.

Five states, joined by evidence rather than inference

The smallest useful AIA record has five layers.

1. Procedure. What is the ballot state? Record SC-104, its immutable base and proposal, the vote receipt, IPR review and the published maintenance Guideline when those events exist. This establishes authority, not implementation.

2. Profile. For the certificate type and Guideline version, what is the outer extension presence level? Record MUST, SHOULD, MAY, MUST NOT or another exact term, whether the extension is critical, and the effective date. This establishes the rule applicable to a defined profile.

3. Method. For every permitted accessMethod, record its OID, function, requirement level, location syntax, maximum count and ordering rule. For this Subscriber Certificate profile, caIssuers and OCSP must remain different rows. This establishes what an extension may or should contain.

4. Issuance. Identify the issuing CA, issuance profile and configuration version, then inspect a specific certificate by fingerprint. Record whether AIA is encoded, each method and location actually present, and the observation time. This establishes bytes, not client behaviour.

5. Reliance. Identify the relying party, product version, platform, policy settings, local store, cache or preload state, server-supplied chain and network conditions. Record whether a fetch was attempted, which source supplied an intermediate, what status mechanism ran and the validation outcome. This establishes one reproducible observation, not an ecosystem truth.

The joins matter. The certificate fingerprint links issuance to reliance. The profile version links issuance to the applicable rule. The Guideline receipt links that profile to an authorised text. But the states must not be merged. A valid certificate under a SHOULD exception can still fail in one client configuration. A certificate carrying both methods can still encounter an unreachable service. A client can validate a chain without an AIA fetch. None of those results rewrites the ballot.

What the evidence cannot settle

The reviewed record contains no measurement of how many current Subscriber Certificates carry AIA, caIssuers, OCSP or both. It does not show how many CAs would change their templates if SC-104 becomes operative. It does not quantify certificate-size savings, privacy effects, network traffic, path-building success, status-checking behaviour or outages. It does not identify a relying party that requested the change.

The proposal’s rationale is still coherent on its own terms: a mandatory container does not guarantee either one particular method when the method rules are SHOULD and MAY. Coherence is not the same as demonstrated benefit. A ballot can rationally align requirement levels while implementers separately measure whether any population depends on the old default.

This boundary cuts both ways. Opponents cannot infer that AIA omission will break every client. Supporters cannot infer that omission is harmless because some clients preload intermediates. The appropriate evidence is a segmented test matrix, not an anecdote selected from either edge.

Make the small change legible

SC-104 is not a redesign of Web PKI. That is precisely why it is a useful governance case. Small normative changes are easily flattened into a changelog sentence, and the flattening conceals where authority ends and operational evidence begins.

The ballot asks whether the outer AIA presence rule should move from MUST to SHOULD while its two permitted methods remain at SHOULD and MAY. Members can decide that question through their established process. Issuers can later decide how to implement an operative rule. Relying parties can continue to make product-specific chain-building and status choices. Server operators remain responsible for their own chain delivery. Those are related decisions, not one decision.

A five-state receipt would not make the ballot heavier. It would make later claims smaller. Instead of saying “AIA became optional” or “clients no longer need it,” an observer could say exactly which text was authorised, which certificate contained which pointer, and which client under which conditions did what.

That is the right scale of proof for a two-line change.

Sources

  1. Lu Heng, “Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption”
  2. CA/Browser Forum servercert pull request 665, SC-104
  3. Immutable SC-104 comparison
  4. CA/Browser Forum servercert issue 673
  5. Public archive of the SC-104 voting notice
  6. TLS Baseline Requirements at the ballot base commit
  7. CA/Browser Forum Bylaws
  8. RFC 5280, section 4.2.2.1
  9. RFC 2119
  10. RFC 8174
  11. Microsoft, Authority Information Access retrieval
  12. Mozilla Security Blog, preloading intermediate CA certificates into Firefox