Summary

  • draft-ietf-opsawg-yang-provenance-07 defines COSE signatures for canonicalized YANG data, providing origin authentication and integrity from the point of signing; it does not guarantee freshness, correctness or an unbroken history of every transformation.
  • A safe automation record must preserve the exact signed element, canonicalization, key mapping, required countersignatures, custody gaps, analytical decision, authorizing principal, controller execution and independently observed outcome as separate coordinates.

The audit console showed a green provenance badge. The original device signature verified. The dataset had not changed since the device signed it.

Yet the controller was not consuming that dataset. An AI preprocessing service had removed outliers, joined an inventory table and emitted a new recommendation. It carried the old signature forward as metadata, but it had produced no signature over its own output and no receipt describing the transformation.

The cryptography survived. The provenance trail did not.

Revision 07 of Applying COSE Signatures for YANG Data Provenance was published on 6 July 2026 and expires on 7 January 2027. It is an active OPSAWG Working Group Internet-Draft whose header proposes Standards Track status. It is not an RFC, completed IANA allocation, interoperability result, deployment survey or security certification. The Datatracker validation snapshot reported four YANG errors and no warnings on 25 August 2026. The draft reports a Java reference implementation and hackathon demonstrations; those are bounded implementation statements, not proof of production adoption.

The signature covers selected canonical bytes

The proposal uses a COSE COSE_Sign1 object with a nil payload. The YANG content is supplied as external data. Before signing or verification, the application selects the exact YANG element required by the enclosing method, excludes the provenance field as specified and canonicalizes the selected representation.

Serialization is part of the contract. CBOR uses length-first core deterministic encoding, JSON uses the JSON Canonicalization Scheme, and XML uses Exclusive XML Canonicalization 1.0. The protected material records the algorithm identifier, a locally interpreted key identifier and the serialization method.

This is useful precision. It lets two systems decide whether the same bounded byte representation was signed by a holder of the corresponding private key. It does not prove that another element outside the selected scope was present, that a schema version expressed the intended business meaning, or that a later conversion preserved every semantic distinction.

A provenance dashboard should therefore never store only signature_valid=true. It needs the signed node or instance boundary, serialization, canonicalization profile, content digest, algorithm, kid, resolved public key, verification time and verifier policy. Without those coordinates, a green result cannot be reproduced.

Origin is local key governance, not a universal identity

The kid is locally agreed and interpreted by signer and verifier. The draft leaves the association between kid and public key outside its scope. It recommends certificates, PKI or another secure out-of-band mapping, but it does not create that trust system.

That means signature validity answers a conditional question: did the private key corresponding to the verifier's current mapping sign these bytes? It does not answer whether the mapping names the right device, domain controller, operating team or human principal. Nor does it say whether that principal was authorised to make the claim at the relevant time.

Key compromise sharpens the point. A stolen but unrevoked key can create a flawless signature. A legitimate key holder can sign measurements that are wrong, fabricated or malicious. The draft states both limits. Origin authentication is evidence about possession of a key, not a truth oracle for the data source.

Countersignatures bind signers to the same content

Additional entities may add full COSE countersignatures. They sit inside the existing signature object without changing the primary signature or the canonicalized content it covers. Each countersigner becomes cryptographically bound to the original signed object.

That is not the same as signing a transformed dataset. If a broker verifies a device message, converts units, drops fields and then countersigns the old object, the countersignature proves its relationship to that old object. It does not make the converted output part of the primary signature input. The broker must separately sign the output or issue a transformation receipt that identifies both input and output.

Verification policy can also be selective. The draft permits checking the primary signature, a subset of countersignatures or all of them according to local policy. Two products can display the same word—“verified”—after evaluating different chains. The receipt must name every required signer, every checked result and every allowed omission.

A chain cannot reveal an absent link by itself

The document is unusually clear about continuity. Iterative signatures can contribute to a provenance trail, but the trail is only as complete as the signatures present. The mechanism alone cannot detect that an intermediate stage failed to sign.

Imagine three systems: a device signs telemetry, an aggregator rewrites it without signing, and an analyst countersigns the original object after receiving both the original and the aggregate. All visible signatures may verify. Nothing inside those signatures proves that the unsigned aggregate is a faithful function of the signed input.

Completeness requires an external expectation: which actors and transformations should have appeared, in what order, under which versioned workflow. Only then can an auditor identify a missing stage. Cryptography can show that a supplied link is intact. Governance must define the links that were required.

Freshness is a separate protocol

A valid object can be old. The draft explicitly excludes inherent freshness and says replay remains possible unless timestamps, nonces or equivalent context are bound into the signature.

This matters most for desired state. A configuration approved last week may still verify after an emergency policy, certificate revocation or maintenance freeze has changed what may be applied today. Replaying the old bytes preserves integrity while defeating current authority.

The evidence record needs a signed observation or policy epoch, creation time, expiry or maximum age, nonce or request identifier, and the verifier's current revocation and authorization state. Wall-clock time by itself is not enough if clocks, time sources or replay windows are ungoverned.

Verification must precede processing—but processing creates a new claim

The draft requires signing to be the last action before the construct is made available and recommends verification before a consumer processes it. That placement closes a useful gap: unverified bytes should not enter an automation chain.

It does not make downstream processing self-authenticating. Schema validation may confirm that a dataset conforms to a model. An AI system may classify it. A rules engine may derive an alarm. A controller may translate that alarm into a command. Each step changes the claim being made.

For AI-assisted operations, model identity and prompt or feature version belong in the receipt. So do preprocessing code, input set, output digest, uncertainty and human or policy approval. A signed input cannot be stretched over an inference it did not contain.

Evidence is not permission

The most dangerous leap occurs after analysis. A provenance signature can help establish where data came from. It cannot authorise a controller to modify a network.

Authority belongs to a principal under a current policy: an operator, change board, delegated service owner or explicitly bounded automation rule. That principal may rely on signed data, but the reliance does not transfer its mandate into the signature. A trusted device key is not automatically a change-authorisation key.

This distinction follows the practical discipline in Heng Lu's notes. Technical evidence can constrain a decision and expose a false story. It cannot manufacture the principal who bears the loss. Running code, operator responsibility and observed service remain outside the cryptographic envelope.

Execution and outcome need their own receipts

Even an authorised command can fail. The controller may reject it, translate it incorrectly, reach only part of a fleet or receive an acknowledgement before the dataplane changes. A later signature on desired state says nothing about these outcomes.

The minimum chain is longer: signed source data; complete transformation record; analytical conclusion; current authorisation; controller acceptance; device configuration state; forwarding or service observation; and rollback or exception state. Each step needs its own subject, time and evidence.

The draft's four enclosing methods—an in-model leaf, YANG-Push notification augmentation, YANG instance-data metadata and a YANG annotation—make provenance easier to carry with data. Leadership should welcome that portability. It should also refuse the convenient fiction that portable evidence is complete evidence.

The useful promise is narrow and strong: these exact canonical bytes were signed by the holder of a key that this verifier mapped to this identity, and they have not changed since signing. Everything after that sentence must be earned separately.

Sources