]> Telefonica

diego.r.lopez@telefonica.com

Telefonica

antonio.pastorperales@telefonica.com

Deutsche Telekom

alex.huang-feng@t-systems.com

Telefonica

ana.mendezperez@telefonica.com

Fraunhofer SIT

Rheinstrasse 75 Darmstadt 64295 Germany henk.birkholz@sit.fraunhofer.de

Operations and Management Operations and Management Area Working Group provenance signature COSE metadata This document defines a mechanism based on CBOR Object Signing and Encryption (COSE) signatures to provide and verify the provenance of YANG data, so it is possible to verify the origin and integrity of a dataset, even when those data are going to be processed and/or applied in workflows where a crypto-enabled data transport directly from the original data source is not available. As the application of evidence-based OAM automation and the use of tools such as AI/ML grow, provenance validation becomes more relevant in all scenarios, in support of the assuring the origin and integrity of data. The use of compact signatures facilitates the inclusion of provenance strings in any YANG schema requiring them. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Operations and Management Area Working Group Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction OAM automation, generally based on closed-loop principles, requires at least two datasets to be used. Using the common terms in Control Theory, we need those from the plant (the network device or segment under control) and those to be used as reference (the desired values of the relevant data). The usual automation behavior compares these values and takes a decision, by whatever the method (algorithmic, rule-based, an AI model tuned by ML...) to decide on a control action according to this comparison. Assurance of the origin and integrity of these datasets, what we refer in this document as "provenance", becomes essential to guarantee a proper behavior of closed-loop automation. When datasets are made available as an online data flow, provenance can be assessed by properties of the data transport protocol, as long as some kind of cryptographic protocol is used for source authentication, with TLS, SSH and IPsec as the main examples. But when these datasets are stored, go through some pre-processing or aggregation stages, or even cryptographic data transport is not available, provenance must be assessed by other means. The original use case for this provenance mechanism is associated with , in order to provide a proof of the origin and integrity of the provided metadata, and therefore the examples in this document use the modules described there, but it soon became clear that it could be extended to any YANG datamodel to support provenance evidence. An analysis of other potential use cases suggested the interest of defining an independent, generally applicable mechanism. Provenance verification by signatures incorporated in YANG data can be applied to any data processing pipeline, whether they rely on an online flow or use some kind of data store, such as data lakes or time-series databases. The application of recorded data for ML training or validation constitute the most relevant examples of these scenarios. This document provides a mechanism for including digital signatures within YANG data. It applies COSE to make the signature compact and reduce the resources required for calculating it. This mechanism is applicable to any serialization of the YANG data supporting a clear method for canonicalization, but this document considers three base ones: CBOR, JSON and XML. In some scenarios, multiple entities may need to provide cryptographic proof over the same provenance information to allow traceability of this content. For this purpose, this specification uses COSE counter signatures . Counter signatures enable traceability of provenance by allowing multiple entities to attest to the same data object over time.

Target Deployment Scenarios The provenance mechanisms described in this document are designed to be flexible and applicable in multiple deployment contexts within operational and management practices. The following non-exhaustive list provides examples of intended deployment scenarios:

• Device Configuration Integrity: Digital signatures may be applied to device configuration elements to ensure that specific configuration fragments originate from an authorized source (e.g., controller, automation system) and have not been altered in transit. This is useful for zero-touch provisioning and secure configuration distribution in programmable networks.
• Telemetry and Monitoring Data: When applied to operational state or telemetry data (e.g., YANG-Push updates or Subscription Notifications), provenance signatures can help verify the integrity and authenticity of data collected from network elements, especially when the data may traverse untrusted collection pipelines.
• Network-Wide Service Orchestration: In multi-vendor or multi-domain environments, provenance can be used to track and validate contributions from different orchestrators or domain controllers in composite service models. This enables trustable service chaining and auditability.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The term "data provenance" refers to information describing the origin of a piece of data and, when available, the history of transformations or transfers it has undergone. The signature mechanisms defined in this document provide integrity protection and origin authentication for YANG data at the time of signing. When applied iteratively by different entities along a data path, these signatures can contribute to building a provenance trail. However, such a trail is only as complete as the set of signatures present and its continuity is not guaranteed by these mechanisms alone.

Defining Provenance Elements The provenance for a given YANG element MUST be convened by a leaf element, containing the COSE signature bitstring built according to the procedure defined below in this section. The provenance leaf MUST be of type "provenance-signature", defined as follows: The use of this type is the proper method for identifying signature leaf instances, and therefore whenever this type is used for a leaf element, it MUST be considered a provenance signature element, to be generated or verified according to the procedures described in this section.

Provenance Signature Strings Provenance signature strings are COSE single signature messages with [nil] payload, according to COSE conventions and registries, and with the following structure (as defined by ): The COSE_Sign1 procedure yields a bitstring when building the signature and expects a bitstring for checking it, hence the proposed type for provenance signature leaves. The structure of the COSE_Sign1 consists of:

• The algorithm-identifier, which MUST follow COSE conventions and registries.
• The kid (Key ID), to be locally agreed, used and interpreted by the signer and the signature validator. URIs and RFC822-style identifiers are typical values to be used as kid.
• The serialization-method, a string identifying the YANG serialization in use. It MUST be one of the three possible values "xml" (for XML serialization ), "json" (for JSON serialization ) or "cbor" (for CBOR serialization ).
• The value algorithm-parameters, which MUST follow the COSE conventions for providing relevant parameters to the signing algorithm.
• The signature for the YANG element provenance is being established for, to be produced and verified according to the procedure described below for each one of the enclosing methods for the provenance string described below.

Use of Countersignatures The primary provenance signature is a COSE_Sign1 message generated over the canonicalized input defined above. Additional entities MAY subsequently apply countersignatures to this COSE_Sign1 message. These countersignatures are integrated within the existing COSE signature object and do not modify the pimary signature input or its value. COSE supports the inclusion of countersignatures as defined in . Countersignatures allow additional entities to provide cryptographic proof over an existing COSE signature without modifying the primary signature value. The inclusion of counter signatures does not alter the original COSE_Sign1 structure, nor the canonicalized input used to produce the original signature. Instead, they extend the COSE object by binding additional signers to the existing signed content. If the canonicalized input used for generating the primary signature is altered, the original signature will fail to validate. Since countersignatures are computed over the original COSE signature object, they remain bound to that original content. As a result, any modification to the underlying data or to the canonicalization process leads to a validation inconsistency across the chain of signatures. This allows verifiers to detect that the data has been altered and to identify the point in the sequence of signatures at which the inconsistency is introduced. In particular, adding counter signatures doesnot change the underlying canonicalized YANG content to which the original COSE_Sign1 signature applies. Countersignatures are composed with the existing COSE signature object, while preserving the primary signature and its association with the same signed content. As a result, the original signature remains unchanged, and every countersignature is added on top of it, binding additional signers to the same signed content. From an encoding perspective, the resulting COSE object, including any countersignatures, is carried within the same provenance leaf, without modifying the YANG data model or the enclosing methods defined in this document. Countersignatures MUST be encoded according to the mechanisms defined in , including the relevant countersignature structures. Provenance signature strings including countersignatures SHALL use full countersignatures according to the definitions in , with context "CounterSignature", and following the same structure as described above for the primary signature in what related to its protected, unprotected and signature fields. Counter signatures SHALL be included in the unprotected header of the COSE_Sign1 object. When multiple counter signatures are present, they SHALL be encoded as an array of COSE_Countersignature structures and carried within the COSE object using the appropriate header parameter defined in .

Signature and Verification Procedures To keep a concise signature and avoid the need for wrapping YANG constructs in COSE envelopes, the whole signature MUST be built and verified by means of externally supplied data, as defined in , with a [nil] payload. The byte strings to be used as input to the signature and verification procedures MUST be built by:

• Selecting the exact YANG content to be used, according to the corresponding enclosing methods.
• Applying the corresponding canonicalization method as described in the following section.
• When countersignatures are present, the same proceduras apply for the generation or verficiation of any countersignature, taking into account the following additinal processing rules:
  • Each counter signature MUST be verifiable independently using the public key of the corresponding signer, as defined by the applicable key identifier carried by the countersignature structure.
  • Verification of provenance information MAY include the validation of the primary signature, a subset of the countersignatures, or all of them, depending on the policy of the verifying entity.

In order to guarantee proper verification, the signature procedure MUST be the last action to be taken before the YANG construct being signed is made available, whatever the means (sent as a reply to a poll or a notification, written to a file or record, etc.), and verification SHOULD take place in advance of any processing by the consuming application. The actions to be taken if the verification fails are specific to the consuming application, but it is RECOMMENDED to at least issue an error warning.

• Note: In deployments where YANG data are transported through message broker systems, verification can be applied after message deserialization and before instance data processing, consistently with the placement described in . In such scenarios, additional schema validation steps (e.g., YANG schema validation performed at the broker level) may complement the provenance mechanism, further strengthening data integrity before application-level processing. The deployment architecture is out of scope for this document, as the provenance mechanisms defined here are intentionally designed for general-purpose applicability across any YANG data processing system.

Canonicalization Signature generation and verification require a canonicalization method to be applied, that depends on the serialization used. According to the three types of serialization defined, the following canonicalization methods MUST be applied:

• For CBOR, length-first core deterministic encoding, as defined by .
• For JSON, JSON Canonicalization Scheme (JCS), as defined by .
• For XML, Exclusive XML Canonicalization 1.0, as defined by .

Provenance-Signature YANG Module This module defines a provenance-signature type to be used in other YANG modules. WG List: Authors: Alex Huang Feng Diego Lopez Antonio Pastor Henk Birkholz "; description "Defines a binary provenance-signature type to be used in other YANG modules. Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2026-06-30 { description "First revision"; reference "RFC XXXX: Applying COSE Signatures for YANG Data Provenance"; } typedef provenance-signature { type binary; description "The provenance-signature type represents a digital signature corresponding to the associated YANG element. The signature is based on COSE and generated using a canonicalized version of the associated element."; reference "RFC XXXX: Applying COSE Signatures for YANG Data Provenance"; } } ]]>

Enclosing Methods Once defined the procedures for generating and verifying the provenance signature string, let us consider how these signatures can be integrated with the associated YANG data by enclosing the signature in the data structure. This document considers four different enclosing methods, suitable for different stages of the YANG schema and usage patterns of the YANG data. The enclosing method defines not only how the provenance signature string is combined with the signed YANG data but also the specific procedure for selecting the specific YANG content to be processed when signing and verifying. Appendix A includes a set of examples of the different enclosing methods, applied to the same YANG fragment, to illustrate their use.

Including a Provenance Leaf in a YANG Element This enclosing method requires a specific element in the YANG schema defining the element to be signed (the enclosing element), and thus implies considering provenance signatures when defining a YANG module, or the use of augmentation to include the provenance signature element in a existing YANG module. When defining a provenance signature leaf element to appear in a YANG schema by means of this enclosing method, the provenance-signature leaf MAY be defined to be at any position in the enclosing element, but only one such leaf MUST be defined for this enclosing element. If the enclosing element contains other non-leaf elements, they MAY define their own provenance-signature leaf, according to the same rule. In this case, the provenance-signature leaves in the children elements are applicable to the specific child element where they are enclosed, while the provenance-signature leaf enclosed in the top-most element is applicable to the whole element contents, including the children provenance-signature leaf themselves. This allows for recursive provenance validation, data aggregation, and the application of provenance verification of relevant children elements at different stages of any data processing pipeline. The specific YANG content to be processed SHALL be generated by taking the whole enclosing element and eliminiating the leaf containing the provenance signature string. As example, let us consider the two modules proposed in . For the platform-manifest module, the provenance for a platform would be provided by augmenting the current schema with the optional platform-provenance leaf shown below: For data collections, the provenance of each one would be provided by augmenting the schema with an optional collector-provenance leaf, as shown below: /p-mf:platforms/platform/id +--ro collector-provenance? provenance-signature +--ro yang-push-subscriptions +--ro subscription* [id] +--ro id | sn:subscription-id + . . . + . . . | . . . ]]> Note how, in the two examples, the element bearing the provenance signature appears at different positions in the enclosing element. And note that, for processing the element for signature generation and verification, the signature element MUST be eliminated from the enclosing element before applying the corresponding canonicalization method. Note that, in application of the recursion mechanism described above, a provenance element could be included at the top of any of the collections, supporting the verification of the provenance of the collection itself (as provided by a specific collector), without interfering with the verification of the provenance of each of the collection elements. As an example, in the case of the platform manifests it would look like: Note here that, to generate the YANG content to be processed in the case of the collection the provenance leafs of the indivual elements SHALL NOT be eliminated, as it SHALL be the case when generating the YANG content to be processed for each individual element in the collection.

Including a Provenance Signature in YANG-Push Notifications The signature mechanism proposed in this document MAY be used with YANG-Push to sign notifications generated directly by publisher nodes. The signature is carried inside the notification envelope header defined in as a new extension. The YANG content to be processed MUST consist of the content defined by the "contents" element in . The following sections define the YANG module that augments the "ietf-yp-notification" module. It extends the notification envelope header with a new leaf for the provenance signature and an augmentation to the "ietf-notification-capabilities" to enable clients discover the support of the provenance signature.

YANG Tree Diagram The following is the YANG tree diagram for the "ietf-yp-provenance" module. And the following is the full YANG tree diagram for the notification structure. ]]> Unlike the first enclosing method, in this second enclosing method the provenance leaf is added by augmenting a structure (/iypn:envelope). The provenance leaf is inserted before the contents leaf. This ordering is important because the provenance signature MUST cover the content of the notification but MUST NOT include itself in the signature computation. This ensures the signature remains valid and verifiable. YANG augmented structures typically respect the convention that the anydata node, when present, should appear as the last element in the structure. Therefore, any newly augmented elements are automatically placed before it.

YANG Module The "ietf-yp-provenance" module augments "ietf-yp-notification" module adding the provenance leaf to the notification envelope structure. It also adds the "notification-provenance" capability to allow clients to discover if provenance signatures are supported. WG List: Authors: Alex Huang Feng Diego Lopez Antonio Pastor "; description "Defines a bynary provenance-signature type to be used in other YANG modules. Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2026-06-30 { description "First revision"; reference "RFC XXXX: Applying COSE Signatures for YANG Data Provenance"; } sx:augment-structure "/iypn:envelope" { leaf provenance { type iyangprov:provenance-signature; description "COSE signature of the 'contents' element of the Notification for provenance verification."; } } augment "/sysc:system-capabilities" + "/notc:subscription-capabilities" + "/iypn:notification-metadata/iypn:metadata" { description "Extensions to Notification Capabilities enabling clients to know whether the provenance signature is supported."; leaf notification-provenance { type boolean; default "false"; description "Support of the provenance signature on YANG-Push Notifications."; } } } ]]>

Including Provenance as Metadata in YANG Instance Data Provenance signature strings can be included as part of the metadata in YANG instance data files, as defined in for data at rest. The augmented YANG tree diagram including the provenance signature is as follows:

• Note: As in the second enclosing method, since this is a data structure, the provenance leaf appears before the content-data element.

The resulting YANG tree structure is: ]]> The provenance signature defined in this enclosing method applies to the whole content of the instance-data-set structure. This is independent of any other provenance signature strings that might be present within the content-data itself through other enclosing methods. The specific YANG content to be processed SHALL be generated by taking the contents of instance-data-set structure, excluding the provenance signature element itself and applying the corresponding canonicalization method.

YANG Module This module defines the provenance signature element to be included as metadata of a YANG data instance. WG List: Authors: Ana Mendez Diego Lopez "; description "This module augments YANG instance data to include a provenance signature for the content-data block, enabling integrity and authenticity verification of the dataset. Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2026-06-30 { description "First revision."; reference "RFC XXXX: Applying COSE Signatures for YANG Data Provenance"; } sx:augment-structure "/id:instance-data-set" { description "Adds a provenance signature to the instance data set envelope."; leaf provenance { type iyangprov:provenance-signature; description "Provenance signature that applies to the full content-data block of an instance dataset. This signature can be used to verify the integrity and authenticity of the instance data."; } } } ]]>

Including Provenance in YANG Annotations The use of annotations as defined in seems a natural enclosing method, dealing with the provenance signature string as metadata extension and not requiring modification of existing YANG schemas. The provenance-string annotation is defined as follows: The specific YANG content to be processed SHALL be generated by eliminating the provenance annotation (encoded according to what is described in Section 5 of ) from the element it applies to, before invoking the corresponding canonicalization method. In application of the general recursion principle for provenance signature strings, any other provenance strings within the element to which the provenance-string applies SHALL be left as they appear, whatever the enclosing method used for them.

YANG Module This module defines a metadata annotation to include a provenance signature for a YANG element. WG List: Authors: Diego Lopez Alex Huang Feng Antonio Pastor Henk Birkholz "; description "Defines a binary provenance-signature type to be used in YANG metadata annotations Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2026-06-30 { description "First revision"; reference "RFC XXXX: Applying COSE Signatures for YANG Data Provenance"; } md:annotation provenance { type iyangprov:provenance-signature; description "This annotation contains the provenance signature for the YANG element associated with it"; } } ]]>

Security Considerations The provenance assessment mechanism described in this document relies on COSE and the deterministic encoding or canonicalization procedures described by , and . The security considerations made in these references are fully applicable here. The considered threat model assumes an attacker with the ability to intercept, observe, copy, replay, or modify YANG data in transit or at rest. The mechanisms defined here protect against data tampering: any modification of signed YANG data will result in signature verification failure, providing integrity protection from the point of signing onward. Additionally, the signature binds the data to the entity holding the corresponding private key, providing origin authentication for the signed data. The following threats are explicitly outside the scope of this mechanism:

• If the signing entity's private key is compromised, an attacker can produce valid signatures; protection against key compromise must be addressed by the key management infrastructure (e.g., PKI, certificate revocation).
• These mechanisms do not guarantee that all intermediate steps in a data path provides a signature: a provenance trail is only as complete as the set of signatures that are present, and gaps in signing by intermediate entities are not detectable by these mechanisms alone.
• A legitimate entity with access to a valid private key may sign incorrect or malicious data; these mechanisms provide no protection against a signing entity that intentionally or unintentionally produces erroneous data.
• Finally, these mechanisms do not inherently guarantee the freshness of signed data; replay of previously signed valid data is not prevented unless additional mechanisms, such as timestamps or nonces bound to the signature context, are employed.

The verification step depends on the association of the kid (Key ID) with the proper public key. This is a local matter for the verifier and its specification is out of the scope of this document. Similarly, key association with reliable data sources is a deployment decision, though a couple of deployment patterns can be considered, depending on the application scenario under consideration. On the one hand, identities may be associated to controller entities (a domain controller, a person in charge of operational aspects, an organizational unit managing an administrative domain, ec.) owning the private keys to be use in generating the provenance signatures for YANG data such as configurations or telemetry. Alternatively, individual devices may hold the identities and corresponding private keys to generate provenance signatures for locally originated data (e.g., telemetry updates). The use of certificates, PKI mechanisms, or any other secure out-of-band distribution of id-public key mappings is RECOMMENDED.

IANA Considerations

IETF XML Registry This document registers the following URIs in the "IETF XML Registry" :

YANG Module Name This document registers the following YANG modules in the "YANG Module Names" registry :

YANG SID-file IANA is requested to register a new ".sid" file in the "IETF YANG-SID Ranges" : A ".sid" file is proposed in Appendix B.

Implementation Status An open-source reference implementation, written in Java, is available at https://github.com/tefiros/cose-provenance. This implementation has been used to generate the examples in the appendix of this document, and was first demonstrated at the IETF 122 Hackathon. Work is ongoing to explore its integration with other open-source YANG modules. A Kafka message broker integration was presented at the IETF 123 Hackathon aiming at convergence with current efforts on YANG Push. The implementation is available at https://github.com/tefiros/kafka-provenance.

References Normative References This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK] YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text. This document defines a YANG extension that allows for defining metadata annotations in YANG modules. The document also specifies XML and JSON encoding of annotations and other rules for annotating instances of YANG data nodes. This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. There is a need to document data defined in YANG models at design time, implementation time, or when a live server is unavailable. This document specifies a standard file format for YANG instance data, which follows the syntax and semantics of existing YANG models and annotates it with metadata. YANG (RFC 7950) is a data modeling language used to model configuration data, state data, parameters and results of Remote Procedure Call (RPC) operations or actions, and notifications. This document defines encoding rules for YANG in the Concise Binary Object Representation (CBOR) (RFC 8949). Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. CBOR Object Signing and Encryption (COSE) defines a set of security services for CBOR. This document defines a countersignature algorithm along with the needed header parameters and CBOR tags for COSE. This document updates RFC 9052. YANG Schema Item iDentifiers (YANG SIDs) are globally unique 63-bit unsigned integers used to identify YANG items. SIDs provide a more compact method for identifying those YANG items that can be used efficiently, notably in constrained environments (RFC 7228). This document defines the semantics, registration processes, and assignment processes for YANG SIDs for IETF-managed YANG modules. To enable the implementation of these processes, this document also defines a file format used to persist and publish assigned YANG SIDs. INSA-Lyon INSA-Lyon Swisscom Everything OPS This document defines a new extensible Notification structure, defined in YANG, for use in YANG-Push Notification messages, both for NETCONF and RESTCONF, enabling any YANG-compatible encodings such as XML, JSON, or CBOR. Additionally, it defines two essential extensions to this structure, the support of a hostname and a sequence number and the support of a timestamp characterizing the moment when the data was observed. n.d. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes configuration data and state data (status information and counters for the collection of statistics). Everything OPS Huawei Telefonica I+D Telefonica I+D Swisscom Network platforms use Network Telemetry, such as YANG-Push, to continuously stream information, including both counters and state information. This document describes the metadata that ensure that the collected data can be interpreted correctly. This document specifies the Data Manifest, composed of two YANG data models (the Platform Manifest and the non-normative Data Collection Manifest). These YANG modules are specified at the network level (e.g., network controllers) to provide a model that encompasses several network platforms. The Data Manifest must be streamed and stored along with the data, up to the collection and analytics systems to keep the collected data fully exploitable by the data scientists and relevant tools. Additionally, this document specifies an augmentation of the YANG-Push model to include the actual collection period, in case it differs from the configured collection period. Swisscom Swisscom This document describes the motivation and architecture of a native YANG-Push notifications and YANG Schema integration into a Message Broker and YANG Schema Registry.

Appendix A. Examples of Application of the Different Enclosing Methods In the examples that follow, the signature strings have been wrapped and, in some cases, indented to improve readability. If these examples are used for any kind of validation, all intermediate carriage returns and whitespace should be deleted to build the actual signature string to be considered.

XML Let us consider the following YANG instance, corresponding to a monitoring interface statement, as defined in : GigabitEthernet1 ianaift:ethernetCsmacd up up 2024-02-03T11:22:41.081+00:00 1 0c:00:00:37:d6:00 1000000000 2024-02-03T11:20:38+00:00 8157 94 0 0 0 0 0 89363 209 0 0 0 0 ]]> Using the first enclosing method, we will demonstrate how to augment the previous ietf-interfaces YANG module by defining it in the new example module below: The following tree diagram illustrates the augmentation of the ietf-interfaces module with a provenance-signature at the root container: The following example illustrates how a provenance signature can be attached to the root interfaces container to protect the entire set of interface configuration and operational data. This augmentation adds a provenance-signature leaf at the root interfaces container (named "interfaces-provenance" in this case) and produces the following output: 0oRRowNjeG1sBGdlYzIua2V5ASag9lhAvzyFP5HP0nONaqTRxKmSqerrDS6C QXJSK+5NdprzQZLf0QsHtAi2pxzbuDJDy9kZoy1JTvNaJmMxGTLdm4ktug== GigabitEthernet1 ianaift:ethernetCsmacd up up 2024-02-03T11:22:41.081+00:00 1 0c:00:00:37:d6:00 1000000000 2024-02-03T11:20:38+00:00 8157 94 0 0 0 0 0 89363 209 0 0 0 0 ]]> The second enclosing method shows a notification with the provenance signature included inside the notification envelope. The provenance element is placed immediately before the contents element: 2024-02-03T11:37:25.94Z 0oRRowNjeG1sBGdlYzIua2V5ASag9lhAzyJBpvnpzI/TirrjckAA29q6Qmf u56L8ZhUXXhu0KFcKh1qSRFx2wGR/y+xgKigVHYicC7fp/0AlHSXWiKB2sg== 1011 GigabitEthernet1 ianaift:ethernetCsmacd up up 2024-02-03T11:22:41.081+00:00 1 0c:00:00:37:d6:00 1000000000 2024-02-03T11:20:38+00:00 8157 94 0 0 0 0 0 89363 209 0 0 0 0 ]]> The third enclosing method, applicable if the instance is to be stored as YANG instance data at rest, by adding the corresponding metadata, would produce a results as shown below: atRestYANG 2024-11-03 For demos Sample for demonstrating provenance signatures diego.r.lopez@telefonica.com 0oRRowNjeG1sBGdlYzIua2V5ASag9lhAWff+fMbfNChKUYZ52UTOBmAlYPFe4 vlZOLyZeW0CU7/2OutDeMCG28+m3rm58jqLjKbcueKLFq8qFJb4mvPY+Q== GigabitEthernet1 ianaift:ethernetCsmacd up up 2024-02-03T11:22:41.081+00:00 1 0c:00:00:37:d6:00 1000000000 2024-02-03T11:20:38+00:00 8157 94 0 0 0 0 0 89363 209 0 0 0 0 ]]> Finally, using the fourth enclosing method, the YANG instance would incorporate the corresponding provenance metadata as an annotation, using the namespace prefix specified in the ietf-yang-provenance-annotation module, as introduced in : GigabitEthernet1 ianaift:ethernetCsmacd up up 2024-02-03T11:22:41.081+00:00 1 0c:00:00:37:d6:00 1000000000 2024-02-03T11:20:38+00:00 8157 94 0 0 0 0 0 89363 209 0 0 0 0 ]]>

JSON Let us consider the following YANG instance, corresponding to the same monitoring interface statement, with JSON serialization: Applying the first enclosing method, a provenance-signature leaf at the top element (named "interfaces-provenance" in this case") would be included following the augmentation module previously defined for the XML example. This will produce the following output: The second enclosing method would translate into a notification including the "provenance" element as follows: The third enclosing method, applicable if the instance is to be stored as YANG instance data at rest, by adding the corresponding metadata, would produce a results as shown below: Finally, using the fourth enclosing method, the YANG instance would incorporate the corresponding provenance metadata as an annotation, using the namespace prefix specified in the yang-provenance-metadata module, as introduced in , and the recommendations in section 5.2.3 of :

CBOR According to , provenance information MAY be represented in CBOR using either YANG names (CBOR diagnostic notation) or YANG SIDs as map keys. The CBOR diagnostic notation when using name keys would be essentially similar to the JSON encoding presented in the previous section. Both representations are included in the examples below to provide a full reference. NOTE TO THE RFC EDITOR: The SID values shown below are illustrative and must be replaced by IANA-assigned values before publication. The first enclosing method will produce the following output, in CBOR diagnostic notation: Note that the provenance leaf in JSON would be represented in BASE64 value and in CBOR diagnostic is a byte string represented with an hexadecimal value. And the corresponding representation of the first enclosing method using YANG SIDs will be: The following example illustrates the notification-based enclosing method (second method), represented in CBOR diagnostic notation. And thhis would be the second enclosing method example in YANG SID notation: The following example illustrates the third enclosing method, represented in CBOR diagnostic notation. And this would be the third enclosing method using YANG SID notation: Note that there is no IANA registered SID for ietf-yang-instance-data:instance-data-set, so a provisional one is used to complete the example. Finaly, the following example illustrates the fourth and last enclosing method using CBOR diagonstic notation: While this last example uses YANG SID notation for the fourth enclosing method: In the example above, the provenance-signature leaf is represented using the proposed assigned SID (3162). The representation of this leaf is the same whether it is added via the first enclosing method (as a direct augmentation of the interfaces container) or via the fourth enclosing method (as an annotation using the yp-provenance-metadata module). The only difference between these two methods is the semantic context and location of the leaf within the YANG data: in the first method it is part of the root container structure, while in the fourth method it is included as metadata in the @ annotation object. From the perspective of CBOR representation, SIDs are identical in both methods. NOTE TO THE RFC EDITOR: Replace the illustrative SID values with the final values allocated by IANA according to .

Appendix B. Provisional YANG SID File (.sid) for ietf-yang-provenance The following .sid file is provided as a provisional example for implementers. It maps schema nodes defined in the ietf-yang-provenance module to numeric SIDs for use in CBOR compact encoding. These SIDs are provisional and will be replaced by IANA-assigned values upon publication of the RFC.

Acknowledgments Thanks to Sofia Garcia (UC3M, sgarciarincon01@gmail.com) for being instrumental in demonstrating the feasibility of the proposed approach, providing a first proof of concept of YANG provenance signatures. This document is based on work partially funded by the EU Horizon Europe projects iTrust6G (grant 101139198), CYBERNEMO (grant 101168182), cPAID (grant 101168407), MARE (grant 101191436), and 6G-DALI (grant 101192750).