Summary

  • RFC 9642 standardises a YANG keystore for symmetric and asymmetric keys, certificates, central references and inline alternatives; it does not certify that a restored key can be used.
  • Encrypted configuration is portable only when the destination can reproduce the KEK and primary-key dependency graph without losing origin, authorization or consumer binding.
  • A recovery receipt joins the exact backup and datastore state to wrapping operations, destination identity, resolved consumers, runtime key operations, certificate rotation and observed service results.

The replacement server accepted the backup without an error. Its <running> tree contained every expected asymmetric key, every certificate name and every encrypted symmetric-key object. The migration report therefore marked the keystore as restored.

The first service restart failed. The ciphertext was present, but the replacement server’s built-in primary key was not the one that had protected the shared key-encryption key. The many leaf nodes had crossed the boundary; the authority needed to open them had not.

That is the operational boundary in RFC 9642. The RFC defines ietf-keystore, a common YANG model for centralised symmetric and asymmetric keys. It gives other modules reusable choices between inline definitions and references to the central keystore. It also describes built-in keys, associated certificates, certificate-expiration notifications and a non-normative pattern for migrating encrypted configuration. None of those objects is a receipt for successful recovery.

A populated tree is configuration evidence

RFC 9642 was published on the IETF Standards Track in October 2024. Its main features separately enable a central keystore, inline definitions, asymmetric keys and symmetric keys. The feature set matters: two servers may claim RFC 9642 support while exposing different admissible forms and therefore different migration paths.

The top-level central keystore is only one possible instance. The reusable grouping exists so a consuming module can instantiate a keystore elsewhere, and the inline-or-keystore choices can be augmented for model-specific locations. A name such as payments-signing-key is a YANG list key, not a global locator, ownership record or immutable identity.

The first layer of a receipt therefore captures the implemented module revision, advertised features, schema context, exact datastore path and content hash. It distinguishes an inline definition from a central reference and records which module consumes the object. A successful parse proves that the data satisfies one structural contract. It does not prove that the consumer resolved the same object, that an HSM accepted it or that an operation succeeded.

System origin is not a manufacturing biography

RFC 9642 follows the Network Management Datastore Architecture in RFC 8342. Operator configuration may appear in <running>. Server-provided built-in keys are expected in <operational> and, when available, <system>, with system origin. A built-in key may have been installed during manufacturing, generated at first boot or created when a service was enabled.

That origin annotation prevents an operator-supplied value from being confused with a server-supplied one. It cannot reconstruct who generated the private value, what entropy or ceremony was used, where the secret resides, whether export is possible, which firmware introduced it or which identity certificate remains valid. RFC 9642 explicitly leaves the vendor process and operator modification of built-in keys outside scope.

When a built-in key is propagated into intended configuration and receives a deployment certificate, a useful inventory preserves the mixed origins. Flattening the result into “configured key with two certificates” destroys the difference between server-provided material and operator-added association. The recovery record should retain both lineages and the exact join.

The encrypted-by edge is part of the asset

RFC 9642 lets encrypted key objects reference either a symmetric or asymmetric encrypting key in the central keystore. That reference is not decoration. It is a dependency edge. At runtime the server must possess the KEK or an API that can use it; otherwise the encrypted key is an opaque backup object.

The standard’s migration pattern makes the consequence visible. Many configured keys can be encrypted by a shared KEK. On the source server, that KEK can in turn be encrypted under a unique built-in primary key. To load the same configuration on a replacement, the shared KEK must be wrapped for the replacement’s primary key. Only that KEK entry changes; the many dependent ciphertexts can remain unchanged.

This is efficient, but it concentrates authority. Whoever can rewrap or replace the shared KEK can affect every dependent key. A missing KEK blocks them together. A mistakenly broadened KEK interface can expose them together. Backup completeness should therefore be measured as graph closure, not a file checksum: all ciphertext objects, every encrypted-by edge, the usable wrapping authority and the destination-specific rewrap must be present and tested.

The migration discussion is non-normative, and the mechanism that installs a primary key is outside the RFC. A report must not say “RFC 9642 recovery succeeded” merely because it followed the diagram. It should name the source and destination devices, their primary-key identities, the shared KEK, algorithms and formats, backup hash, authorized crypto officer or service, rewrap request, verification result and rollback object.

Encryption protects bytes, not continuity

The security section recommends encrypting keystore contents at rest and zeroising decrypted volatile copies when not in use. If persistent contents are not encrypted, storage must be inaccessible. Those are important implementation expectations. The YANG data itself cannot demonstrate that disk encryption covered every replica, that memory was cleared, that crash dumps were excluded or that backup operators lacked another path.

RFC 9640 supplies the reusable cryptographic types and hidden, encrypted and cleartext representations that RFC 9642 uses. The distinction remains exact: hidden means the management model does not return the secret through that surface; it is not a universal non-extractability claim. encrypted means ciphertext has been represented with a format and wrapping reference; it is not a guarantee that the KEK is protected, available or authorised.

The recovery receipt therefore includes storage and memory controls as implementation evidence, not as properties inferred from the node type. It records backup encryption, custody, access logs, restore environment, volatile handling and negative tests. When hardware evidence is unavailable, the assertion must narrow rather than borrow certainty from the word “keystore”.

Access control is a gate, not a history

All writable nodes in ietf-keystore carry nacm:default-deny-write; cleartext secrets inherited from RFC 9640 receive stronger default read denial. RFC 8341 provides the policy mechanism. It does not preserve the event that matters.

A change record still needs the authenticated NETCONF or RESTCONF session, transport binding, active NACM policy version, matched rule, actor, requested path, before-and-after object, commit result, approval and operational projection. It should also state which privileged local, vendor or hardware interfaces sit outside the YANG path. A denied management write proves one policy decision at one boundary, not the immutability of the key.

NETCONF and RESTCONF give secure management contexts. RFC 9642 itself defines no RPC or action. Key generation and encryption may be supplied by consuming SSH or TLS models or performed externally by a crypto officer. The tree therefore cannot identify a generation ceremony unless a separate record is joined to it.

Association is not consumer activation

An asymmetric key may carry one or more certificates. An end-entity certificate reference selects both the asymmetric key and a named certificate. Verified Errata 8441 corrects a copied explanatory sentence that called this a symmetric-key choice; the actual structure is an asymmetric key/certificate pair.

Even a correct pair does not prove that a service selected it. RFC 9644 and RFC 9645 show how SSH and TLS consumer models can depend on keystore material. A complete record resolves the consumer’s reference, captures its configuration revision, observes the key operation and binds the resulting session or service behavior to the selected object.

RFC 9642 also leaves private-key usage unconstrained. A key present in the keystore is not inherently limited to signing, decryption or another operation. Certificate key usage may constrain the associated public key, but organisational permission and actual private-key use remain separate decisions. Recovery tests should verify the intended operation and reject unintended ones.

Expiration starts work; it does not finish it

Where the feature is enabled, a certificate may emit an expiration notification. The event reports a date condition. It does not prove subscriber delivery, acknowledgement, replacement approval, certificate attachment, consumer reference update or successful post-rotation service.

The evidence chain should continue from event identifier and delivery through the new certificate bytes, matching public key, chosen consumer, deployment state and observed handshake or cryptographic operation. A restored backup may reintroduce an older certificate after a rotation. A central key may hold the new certificate while an inline consumer still uses the old pair. Both cases look complete if the audit stops at inventory.

Build the recovery receipt

Start with the exact backup object, module revision, features, schemas, source datastores and origin annotations. Preserve every key and certificate fingerprint, encrypted-value format and encrypted-by edge. Name the source primary key, shared KEK, destination primary key and the authorised rewrap operation.

Then verify the destination state. Did the rewrapped KEK load? Could it unwrap each required dependent object? Did central and inline references resolve to the intended versions? Did the correct certificate remain attached? Did each consumer select the object? Did the intended runtime operation succeed, and were prohibited operations refused? Did the service produce the expected bounded outcome?

Finally, preserve rollback and expiry state. A recovery is not complete when a tree imports; it is complete only to the scope of the tested consumers and operations. That discipline respects the purpose of a minimum shared specification. RFC 9642 coordinates representations and references. Running code exercises cryptographic authority. The receipt keeps those realities joinable without declaring them identical.

Sources