Summary

  • RFC 9640 standardises reusable YANG types and groupings for passwords, keys, certificates, encrypted values and certificate requests; it does not define a complete custody system.
  • A hidden-key proves that the value is unavailable through the modelled management interface, not that it was generated inside an HSM or is nonexportable through every path.
  • A defensible receipt joins schema state to session identity, NACM evaluation, approval, datastore commit, key origin, trusted boundary, runtime use and verified lifecycle events.

The security review opened the configuration tree and found the private key represented as hidden. No cleartext value came back through NETCONF. The reviewer marked the control complete: key protected in hardware.

The first observation was supported. The second had been invented. In RFC 9640, a hidden private or symmetric key is inaccessible through management interfaces while remaining available to the server for cryptographic operations. The grouping says nothing about whether the bytes live in an HSM, a process heap, an encrypted file or a remote service. It explicitly leaves creation outside its scope.

That gap is not a defect. It is the boundary that makes the module reusable. ietf-crypto-types supplies common identities, typedefs and groupings so other YANG modules do not invent incompatible representations for every password, key, certificate or certificate signing request. The operational mistake begins when a precise representation is promoted into evidence about a layer it never observed.

A type is a common language, not a ceremony

RFC 9640 was published on the Standards Track in October 2024 by the IETF NETCONF working group. Its typedefs carry DER-encoded ASN.1 objects such as PKCS #10 certificate requests, X.509 certificates, revocation lists, OCSP messages and CMS structures. Its groupings compose encrypted values, passwords, symmetric keys, public and private keys, asymmetric pairs, certificates and a reusable CSR action.

Those are valuable minimum building blocks. A consuming module can say exactly which form it accepts and a server can validate the shape. Operators gain a shared vocabulary across NETCONF and RESTCONF implementations. Yet the module is deliberately not a complete keystore or truststore. RFCs 9642 and 9641 define those neighboring models.

Early generic key-generation RPCs were removed because the working group did not reach consensus on how algorithms should be identified. RFC 9640 consequently supports keys configured by an external client and permits protocol-specific modules to define generation. If a tree contains a key, the tree can tell us about the accepted state. It cannot reconstruct the missing ceremony: who requested generation, which entropy and algorithm policy applied, whether attestation was checked, who witnessed import, or where the first exportable copy existed.

Hidden is a management-plane statement

The choice among cleartext, hidden and encrypted values looks like a security ladder, but each option answers a different representation question.

Cleartext password and key features are optional and their use is not recommended. When enabled, sensitive readable values carry nacm:default-deny-all. Hidden values are not returned through management interfaces, but the server can use them. Encrypted values can carry CMS EncryptedData or EnvelopedData. The generic encrypted-by container is empty: the consuming module must augment it with a reference to the key that performs the wrapping.

None of these forms is a custody verdict. A hidden key may have been imported in cleartext before becoming hidden. Another local API may expose it. A crash dump may capture it. A privileged process may use it outside the intended purpose. Conversely, a software-held key can be well controlled without pretending to be hardware-bound. The receipt must name the boundary instead of inferring it from the absence of a field.

Encryption creates another dependency rather than eliminating custody. RFC 9640 requires a proper symmetric mode such as AEAD or CBC with a random IV and forbids ECB. That is an important algorithmic floor. The encrypted blob still needs a wrapping key whose identity, availability, authorization, rotation and recovery are demonstrable. A backed-up ciphertext with a lost wrapping key is not resilient; a ciphertext with an overexposed wrapping key is not protected.

Default deny is policy input, not the audit trail

RFC 9640 applies restrictive NACM defaults to cryptographic material. Key and password writes are denied by default, and cleartext secret reads are denied to all unless a more specific rule permits them. Certificate data receives protection too, because even public certificates may reveal identifiers and communication patterns. Altering public keys or certificates can redirect trust, so writable nodes also deserve caution.

The annotations matter. They force a consuming implementation to begin from restraint rather than convenience. But default-deny-all is not a recording of what happened on Tuesday at 14:03. An audit needs the authenticated NETCONF or RESTCONF session, the rule set and revision actually loaded, the matched NACM rule, the requested path and operation, the before-and-after datastore, the commit outcome and any higher-level approval.

Secure transport and mutual authentication likewise do not collapse identity into authority. A certificate can identify a device or operator while the organization still has to decide whether that principal may import this key for this service. Transport proves a channel property. NACM decides a model access. Change governance authorizes a business effect. The cryptographic engine later performs—or refuses—the operation. Each layer needs its own evidence.

Matching prevents one class of error

RFC 9640 requires useful structural consistency. When a client supplies both sides of an asymmetric pair, the server must ensure that the public and private keys match. When certificates accompany a pair, the server must ensure that each certificate contains the corresponding public key.

That receipt is narrow and strong: these objects belong together mathematically. It does not show that the private key was generated under an approved policy, that the certificate authority performed legitimate validation, that the certificate is currently acceptable, or that an application selected the key for the intended operation.

The generic groupings intentionally impose no usage constraints. A public key is not limited by the grouping to encryption or verification; a private key is not limited to decryption or signing. Protocol-specific models and local policy must say what operations are permitted. Otherwise a mathematically consistent pair can be operationally overpowered.

A CSR is an output, not an enrolment outcome

The reusable generate-csr action is protected with default-deny-all. RFC 9640 recommends channel binding so the application requester is the same device authenticated at the secure transport layer. That recommendation exposes a common seam: an authenticated connection, a permitted action and an organizational mandate are related but not identical.

A complete CSR receipt should bind the transport identity, application identity, authorization decision, exact subject and extension inputs, selected key reference, resulting CSR digest and timestamp. The next chain begins at the certification authority: submission, validation, approval, issued certificate, public-key match, installation and first successful use. A valid CSR only proves that a request object was generated; it cannot testify that an authority accepted or deployed it.

Deletion is a datastore event before it is erasure

RFC 9640 says cleartext key values should be zeroized when deleted. That is an essential implementation requirement. It is not self-proving.

When a node vanishes from a YANG tree, an observer can establish a datastore transition. Memory copies, journal records, replicas, backups, swap, crash dumps and accelerator buffers may have different lifetimes. “DELETE returned success” must not become “all recoverable material was destroyed” without evidence from the implementation and storage boundary.

A credible erasure record names the server and version, every storage and replication domain in scope, the deletion transaction, overwrite or hardware-destruction mechanism, backup expiry, verification procedure and residual exceptions. Where forensic zeroization cannot be proved, the organization should state the narrower result and manage the remaining exposure.

Assemble the custody receipt

Start with the exact module revision, enabled features and schema path. Record the protocol, secure-channel peer and channel binding, then the NACM policy version and evaluated rule. Preserve the candidate and running datastore states, commit identifier and approval object.

For the key itself, record generation or import provenance, algorithm and parameters, public fingerprint, trusted execution or storage boundary, extractability setting and permitted operations. For encrypted forms, bind the ciphertext to the wrapping-key reference and prove that recovery is both possible and controlled. Keep key-pair and certificate matching results as their own checks.

Runtime use requires a second receipt: requester, authorization, exact operation, key version, input/output digest, time, implementation and outcome. Rotation, revocation, backup and deletion close the lifecycle. This chain lets a precise YANG model do what it does best—provide a common, inspectable interface—without conscripting it as proof of every unseen reality.

Sources