Summary

  • RFC 9641 defines reusable YANG truststores made of named certificate and public-key bags, with central references and inline alternatives; it does not record a completed authentication decision.
  • A central bag can coordinate one anchor update across many consumers, but that efficiency also enlarges the blast radius and makes the exact resolved object at decision time essential evidence.
  • A defensible receipt joins configuration origin and access control to the peer object, certification path, validation time, service identity, purpose, revocation policy, verifier result and later authorization.

The incident record said that a TLS client trusted its peer because its configuration contained a leafref to production-server-anchors. The reference resolved. The bag existed. Its certificate was syntactically valid. The record then jumped to its conclusion: peer accepted under approved trust.

That last sentence was not yet supported. A leafref can establish that one configuration node points to another. A trust-anchor bag can establish the objects available to a consuming model. Neither fact identifies the certificate presented in a particular handshake, the path the verifier built, the clock it used, the service name it checked, the purposes it permitted or the reason it returned success.

RFC 9641 is valuable precisely because it does not pretend to own all those decisions. It supplies ietf-truststore, a reusable management model for central bags of certificates and raw public keys, plus groupings that let another module choose between an inline definition and a central reference. The standard creates a common configuration surface. The operating institution still has to preserve the receipt that connects that surface to one runtime judgment.

The bag is an input boundary

RFC 9641 was published on the Standards Track in October 2024 by the IETF NETCONF working group. Its certificate bags and public-key bags collect anchors intended for a common purpose. Certificate-bag purpose should be described; public-key-bag purpose must be described. That description is a necessary governance signal, but it is not executable proof that every consumer enforced the same scope.

The generic model treats configured trust anchors as implicitly trusted for path validation. Unless a consuming context or auxiliary policy narrows them, those anchors may validate paths containing any name and may be used for any purpose. This is an intentionally broad foundation. Protocol-specific models—such as the TLS client and server groupings in RFC 9645—must supply the context in which a bag is selected and used.

Therefore a bag named “production servers” does not by itself enforce production, servers or even certificate-path validation. A raw public-key consumer has different checks from an X.509 consumer. An application may add name constraints, extended-key-usage rules, algorithm policy, pinning or a private authorization map. The receipt must report the rules actually executed rather than borrowing certainty from the bag’s label.

Central and inline trust can contain the same bytes but different authority

RFC 9641’s inline-or-truststore groupings make a mandatory choice when the corresponding features are supported. A consuming service may carry its anchors inline or refer to a central bag. At one instant, the two configurations can resolve to identical DER bytes and make the same validation decision. Their future behavior is not equivalent.

Centralisation gives one owner an efficient update surface. Replacing a compromised or expiring anchor once can repair every correctly referencing consumer. It also means one mistaken addition, deletion or replacement can alter the acceptance surface of many services at once. A bag name is mutable; it is not a durable description of the objects used yesterday.

Inline anchors localise change and rollback. They also invite drift: one service receives the new anchor, another keeps the old one, and a third accumulates both. Neither architecture is inherently safer. The relevant questions are who may change the object, which consumers inherit the change, how the exact version is identified, what rollback restores, and how running behavior is observed.

A useful runtime record therefore resolves the reference. It preserves the selected bag and object identifiers, certificate or public-key bytes or cryptographic fingerprints, datastore origin, revision or content hash, consuming configuration path and the moment at which that resolution occurred. “Used central truststore” is an architectural statement. “Validated with this anchor version” is an event statement.

System origin does not reconstruct provenance

Some devices ship built-in anchors for manufacturer services, secure bootstrap or public certification authorities. RFC 9641 expects such material to appear in operational state and, where the system datastore is implemented, in system configuration, carrying system origin rather than ordinary intended-configuration origin.

That distinction prevents a useful lie. A reader should not mistake vendor-supplied state for an operator-authored change. But system origin is still a classification, not a manufacturing history. The RFC leaves the method for setting or modifying built-in anchors to the implementation. Operational presence cannot tell an auditor which build introduced the anchor, who approved the manufacturing image, how update authorization was verified or whether the consumer selected that anchor during a disputed session.

Secure zero-touch provisioning in RFC 8572 illustrates why the distinction matters: bootstrap trust can decide which controller acquires later authority. An inventory that flattens intended, system and operational origin into one “trusted certificates” list destroys the evidence needed to investigate that transfer.

Default-deny-write protects a door, not the whole room

Truststore objects and references use nacm:default-deny-write. Under the Network Configuration Access Control Model in RFC 8341, ordinary writes begin from denial unless policy grants them. This is appropriate even for public keys and certificates: changing public material can redirect whom the server accepts.

The annotation is not a historical record. A change receipt still needs the authenticated NETCONF or RESTCONF identity, secure channel, active NACM rule set, matched rule, requested path, before-and-after value, datastore commit, approval and final operational projection. The datastore architecture in RFC 8342 helps distinguish intended and operational views; it does not make them identical.

RFC 9641 also draws a sharp storage boundary. Management APIs and NACM address data in motion and access through those APIs. YANG cannot prescribe how truststore data is protected at rest. The implementation must prevent unauthorised modification in files, databases, firmware, backups or privileged local paths. A denied NETCONF edit does not prove that a root process, package update or storage corruption could not change the same anchor.

Expiration is a signal, not a completed repair

Where supported, a certificate entry may emit a certificate-expiration notification as expiry approaches or arrives. The notification reports a condition. It does not prove that a subscriber was connected, that delivery succeeded, that an operator acknowledged it, that replacement material was approved, or that every consumer resolved the new certificate.

An expiration receipt should join feature support and notification configuration to the emitted event, delivery identity, acknowledgement, replacement object, changed references, deployment state and the next successful validation. It should also preserve the failed branches: a replacement may be present but unused; a central bag may be current while an inline consumer remains stale; a certificate may be unexpired yet fail name, usage, policy or revocation checks.

Path validity is only one stage of acceptance

For X.509, RFC 5280 defines certification-path validation. A verifier still has to assemble or select a candidate path, process constraints and decide whether the result satisfies local policy. For application services, RFC 6125 separates service-identity matching from merely building a valid path. TLS 1.3 supplies the handshake context in which certificates and signatures are exchanged.

The evidence chain should name the exact peer certificate or raw public key, session identifier, resolved bag and anchor, candidate and accepted path, validation time and clock source, validity results, reference identity, matching rule, key usage, extended key usage, name constraints, certificate policies, algorithm decisions and revocation evidence required by local policy. It should identify the verifier and version and retain the reasoned outcome, including a machine-readable failure reason.

Authentication still does not grant application authority. A correctly authenticated peer may be allowed to read telemetry but not change routing policy; a valid manufacturer service may be unsuitable for an operator’s production plane. Record the post-authentication authorization decision as a separate step, bound to the authenticated identity and requested action.

Build the acceptance receipt

Begin with the module revision, enabled features and exact configuration path. Preserve whether the anchor was inline, central or built in; the intended, system and operational origin; the actor and approval behind any change; and the at-rest integrity evidence appropriate to the implementation.

At runtime, bind the consuming service and configuration version to the exact resolved bytes. Add the peer object, session, path, time, name, purpose, algorithm and status checks, verifier result and authorization outcome. When a central bag changes, enumerate every known consumer and compare pre-change and post-change acceptance. When an expiration signal fires, follow it through acknowledgement, replacement and verified use.

This layered receipt does not weaken RFC 9641. It lets the standard do its proper job: provide a minimum shared trust vocabulary across autonomous implementations. The bag coordinates an input. The running verifier decides an event. The institution remains responsible for proving how one became the other.

Sources