Who approved the Company-Certs anchor rollover?

Summary

A current individual Internet-Draft proposes /.well-known/company-certs as an HTTPS discovery point for application-specific private-CA trust anchors, constrained by usage, validity and permitted domains rather than installed in the operating system’s global store.
A successful fetch authenticates an origin and a metadata object, not the organisation’s internal decision to introduce, replace or retire an anchor. During an overlap, the newest applicable valid_from can change client trust without showing who approved that change.
Daniel Kade proposes a trust-anchor change receipt joining the exact metadata epoch, old and new fingerprints, application scope, overlap window, approving authority, local client policy, corroboration and rollback path. This is editorial guidance, not an IETF requirement.

Every technical check can pass

The cleanest way to see the seam is to remove the attacker. Suppose an organisation has one application-specific certificate chain in service and publishes a second chain for rollover. Both entries are inside their declared validity intervals. Both are scoped to the same usage context and permitted domains. The client retrieves the object over correctly authenticated HTTPS and validates its JSON structure. Under the proposed selection rule, it chooses the applicable chain with the most recent valid_from, unless local policy says otherwise.

Nothing in that sequence is necessarily wrong. A planned overlap is a sensible way to move relying applications without a simultaneous cutover. Origin authentication is valuable. Scope constraints are valuable. A client that consistently follows a published rule is easier to reason about than one that improvises.

Yet the sequence proves less than an operational dashboard is likely to claim. It shows that the holder of the origin’s effective publication capability served a particular object. It does not show that a named PKI owner, a security role, a change board or an approved automation authorised the new anchor for that application. It does not show that the overlap was intentional, that the old anchor should now be retired or that a cached client saw the same epoch as another client.

That missing join matters because a trust anchor is not merely another certificate. It is an input to the relying party’s validation decision. Once accepted, it can make otherwise untrusted paths acceptable for the bounded application context. The publication surface therefore carries a delegated power to alter what the application recognises as an authority.

What the draft actually proposes

draft-doehle-company-certs-discovery-00 is an individual Internet-Draft dated 22 July 2026. It is intended for the Standards Track, but at this cutoff it remains revision -00, has no RFC status and may change or expire. Its purpose is specific: let an organisation publish application-specific trust-anchor metadata at /.well-known/company-certs over HTTPS.

The object is versioned JSON. It contains authority information and a set of trust anchors. Each anchor is associated with a usage_context and one or more certificate chains. A chain can identify a validity interval, a same-origin HTTPS location for CA material, a PEM X.509 chain, revocation endpoints and a SHA-256 fingerprint. Constraints can narrow the anchor to permitted domains and state that an isolated trust store is required.

This is not a proposal to install a private CA into the operating system’s global trust store. It does not replace the public Web PKI, enroll end-entity certificates or declare a private CA globally trustworthy. Its attractive property is isolation: a particular application can discover the trust material it needs for a bounded relationship without changing every other TLS decision on the device.

The draft is equally clear about the publication boundary. HTTPS certificate validation is mandatory. permitted_domains cannot wander arbitrarily; a name must be identical to or subordinate to a DNS identifier in the validated endpoint certificate. The CA-chain URL is same-origin HTTPS. These limits keep the mechanism tied to the organisation’s domain rather than turning it into an open directory of unrelated trust.

The limits also reveal the governance question. Domain control establishes authority to publish for the origin. The draft says it does not independently attest the quality, security or operational trustworthiness of the published CA. It cannot see how the organisation divided access to DNS, hosting, content delivery, TLS keys, repository deployment and PKI administration.

Origin authority is not rollover authority

RFC 8615 standardises the .well-known namespace so applications can discover site-wide metadata at predictable paths. Its security discussion warns that write access to a well-known resource can amount to authority over an entire origin. In a co-hosted environment, filesystem or deployment permissions may therefore confer more power than their operator realises.

That warning is architectural, not an accusation. A company may protect the endpoint exceptionally well and still need to decide what its protection proves. The web team may control deployment. The network team may control DNS. A content-delivery provider may serve the object. A certificate operations team may issue the private CA. An application owner may decide which usages are acceptable. A risk authority may approve the rollover. “The domain published it” compresses all of those functions into one sentence.

RFC 9525 makes a parallel distinction at the connection layer. Reference-identity verification helps a client decide whether the presented TLS identity is authorised for the name it intended to reach. Passing that test is not a signed statement about the publisher’s internal change-control process. The endpoint can be the correct endpoint and the trust decision can still lack a traceable mandate.

The distinction should survive even when deployment is fully automated. Automation can be the approving mechanism, but only if the organisation has bounded its authority: which usage contexts it may change, which old and new anchors it may join, which corroboration it requires, how long an overlap may last and who can stop or reverse the transition. A pipeline run is evidence of execution. It is not self-authenticating evidence of mandate.

The newest timestamp is a selection rule

The draft’s handling of overlapping chains is operationally important. A client ignores a chain outside its validity interval. If multiple chains still apply to the same usage context, it selects the one with the most recent valid_from, unless local policy overrides the rule. That is a deterministic way to choose. It is not an approval protocol.

Timestamps answer ordering questions. RFC 3339 helps systems express Internet dates and times consistently. It cannot say why a time was assigned, whether a rollover window was approved, or whether two independent operators intended the same transition. A malicious or mistaken publisher can place a later value in syntactically valid JSON just as an authorised publisher can.

The gap becomes sharp during an overlap. The old path may continue to validate under RFC 5280 while the new path also validates against its new locally supplied anchor. The application’s decision changes because the metadata ordering changed, not because certificate path validation discovered an organisational mandate. RFC 5280 consumes trust anchors as inputs; it does not certify the business process that selected them.

This does not make the most-recent rule defective. Any automated rollover needs a selection rule. The governance mistake is to let that rule inherit more authority than it was designed to carry. “The client selected the newest applicable chain” is a useful, precise statement. “The organisation approved the new trust anchor” requires different evidence.

Isolation is a promise that clients must keep

isolated_store_required is another carefully drawn boundary. It communicates publisher intent that the discovered anchor be confined to the application-specific context. The draft explicitly notes that the field is not technical enforcement. A client unable to provide isolation should reject the anchor instead of silently broadening its influence.

This creates two auditable decisions. The publisher decides that isolation is required. The client determines whether its actual trust-store architecture can enforce that requirement. Merely recording the boolean value proves neither. The application needs evidence of where the anchor was stored, which validation calls can reach it and whether a shared library or operating-system integration widened its scope.

The permitted-domain constraint works similarly. It limits the names for which a chain may be used, but a local implementation still has to apply it during every relevant validation. A configuration parser can accept the field while the path builder ignores it. A shared cache can mix usage contexts. A later refactor can move an anchor from a private collection into a common pool. The governance record must connect declared scope to observed enforcement.

This is why “we never changed the global store” should be tested rather than inferred. Application isolation is the mechanism’s strongest safety claim. Losing it turns a bounded discovery convenience into a much broader trust decision.

Fresh HTTPS can carry stale authority

Transport freshness and decision freshness are different clocks. RFC 9110 and RFC 9111 give HTTP a rich caching model. A response can be fresh under its cache controls, stale but revalidated, or retained under a client’s local policy. The draft urges conservative caching, periodic revalidation and resistance to replay or stale metadata, and permits a client to impose its own maximum freshness.

Those controls answer whether the client has a sufficiently recent representation of the origin’s object. They do not answer whether the organisational approval behind the object is still live. An emergency exception may have expired while a cache remains fresh. A security role may have withdrawn a change while one edge still serves the previous epoch. A new object may be current at the origin but unauthorised by the team that owns the relying application.

The first successful retrieval deserves special treatment because it is a bootstrap. Before that moment the application has no anchor from this channel. After it, the application may accept certificate paths that were impossible a moment earlier. The draft identifies this first retrieval as sensitive. An operator should therefore be able to distinguish first enrolment, routine refresh, overlap, cutover, removal and emergency rollback rather than present them all as identical GET requests.

Polling adds a privacy dimension. Retrieval can reveal interest in an organisation and a usage context. Reducing unnecessary requests protects both infrastructure and information. That makes a well-designed local cache desirable, but it also makes the cache horizon part of the trust decision. The right interval cannot be derived from HTTP mechanics alone; it depends on how quickly an unauthorised or mistaken anchor must cease to influence validation.

Revocation does not revoke an approval

The metadata can point to CRL or OCSP information. RFC 6960 lets a relying party obtain status about certificates. That is useful when an issued certificate should no longer be accepted. It answers a different question from whether the root or intermediate trust material was validly introduced.

A new anchor can be perfectly usable while its publication was not approved for the application. An old anchor can remain cryptographically valid after the organisation intended to retire it. An OCSP response about an end certificate does not reconstruct the change authority for the anchor set. Even a complete revocation service cannot explain why the client changed from one trust basis to another unless the transition itself has an identity.

Removal is also not always an instant correction. Cached metadata can persist. Long-lived sessions may not rebuild a path. Offline clients may reappear with an old object. An application could have copied the anchor into another store. The correction plan must therefore name not only the object to remove, but the populations to revalidate, the maximum propagation delay and the evidence that isolation held.

A trust-anchor change receipt

Daniel Kade’s proposal is a trust-anchor change receipt for each material Company-Certs transition. It is not a new field demanded of the public JSON object, and it is not an IETF requirement. It is the operational record that prevents origin-authenticated publication from being misreported as complete organisational authorisation.

The receipt begins with the exact metadata epoch: a digest of the retrieved object, the origin, the validated reference identity, retrieval time and the cache or revalidation state. It records the usage context, permitted-domain set and isolation requirement. This keeps the approval tied to one bounded object rather than to whatever the endpoint may publish later.

It then names the transition. Old and new anchor fingerprints, chain identifiers, valid_from, valid_until, overlap window and intended cutover state belong together. A replacement is different from an addition; an emergency rollback is different from routine overlap; removal of the old anchor is different from merely preferring the new one.

The authority component identifies the approving role, policy or bounded automation and the change record it authorised. This need not expose private board minutes or a person’s name at the public endpoint. A protected internal reference, signed decision digest and scoped role can be sufficient. What matters is that investigators and operators can prove the mandate independently of the same publication path that executed it.

The client component records local policy. Did the client use the draft’s most-recent rule or an override? Did it require out-of-band corroboration for the first retrieval or a root change? Could it enforce the isolated store and permitted domains? When must it revalidate? What happens when the endpoint is unreachable or the receipt is absent?

Finally, the receipt contains correction state: revocation locations, rollback eligibility, emergency removal, affected client classes, maximum propagation time and closure evidence. The receipt itself expires. An approval for one metadata digest and one overlap window must not legitimise a different anchor added months later.

Corroboration should match the consequence

Not every application needs a ceremony-heavy rollover. An internal test service with narrow privileges may accept origin authentication plus a repository approval. A signing service, payment system or infrastructure control plane may require a second channel controlled by a different role. The receipt should express that policy difference instead of pretending every anchor has equal consequence.

Out-of-band corroboration also needs precision. A message sent by the same compromised account is not independent. A second URL on the same deployment path may not be independent. Useful separation can come from a PKI control system, a signed release manifest, a protected change ledger, a hardware-backed approver key or a second administrative domain. The evidence should be proportionate and should not expose new sensitive material merely to appear thorough.

RFC 5011 provides a bounded comparison. In DNSSEC’s automated trust-anchor update domain, add, hold-down and remove states make transition time explicit. Those rules do not govern Company-Certs and should not be copied mechanically. The lesson is narrower: when software is authorised to change its own trust basis, the change is important enough to have durable transition state rather than a single undifferentiated “current” value.

The draft leaves this question open

An individual Internet-Draft should not be criticised for failing to encode an entire organisation’s governance. Its value is that it draws a useful technical boundary: a domain-scoped, HTTPS-delivered, application-specific trust-anchor mechanism with explicit validity, scoping and isolation signals. That is already more disciplined than emailing a CA file or placing it silently in a global store.

The governance layer begins where the protocol’s evidence ends. The draft supplies no proof of a named deployment, incident, breach or common implementation. The opening scenario is a bounded design test derived from its multiple-chain selection rule, not an allegation that any company has performed an unauthorised rollover.

The design can mature without making the public endpoint a bureaucracy. The essential move is to preserve distinct verbs. HTTPS authenticates retrieval. JSON represents metadata. path validation tests a chain under local inputs. client policy selects an applicable anchor. organisational authority approves a change. A receipt joins those decisions without pretending one can substitute for the others.

A Company-Certs Endpoint Cannot Prove Who Approved a Trust-Anchor Rollover

Why it matters

Summary

Every technical check can pass

What the draft actually proposes

Origin authority is not rollover authority

The newest timestamp is a selection rule

Isolation is a promise that clients must keep

Fresh HTTPS can carry stale authority

Revocation does not revoke an approval

A trust-anchor change receipt

Corroboration should match the consequence

The draft leaves this question open

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing