]> Universität Bremen TZI

Postfach 330440 Bremen D-28359 Germany +49-421-218-63921 cabo@tzi.org

CDDL models A number of CBOR- and JSON-based protocols have been defined before CDDL was standardized or widely used. This short draft records some CDDL definitions for such protocols, which could become part of a library of CDDL definitions available for use in CDDL2 processors. It focuses on CDDL in (almost) published IETF RFCs. About This Document Status information for this document may be found at . Discussion of this document takes place on the core Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction (Please see abstract.) Add in

CDDL definitions for (almost) published RFCs This section is intended to have one subsection for each CDDL data model presented for an existing RFC. As a start, it is fleshed out with three such data models.

RFC 7071 (Reputation Interchange) contains two CDDL definitions for , which are not copied here. Typically, the compact form would be used in applications using the RFC 7071 format; while the extended form might be useful to cherry-pick features of RFC 7071 into another protocol.

RFC 8366 (Voucher Artifact for Bootstrapping Protocols) defines a data model for a "Voucher Artifact", which can be represented in CDDL as:

CDDL for RFC 8366 ) assertion: assertion serial-number: text ? idevid-issuer: json-binary pinned-domain-cert: json-binary ? domain-cert-revocation-checks: bool } } assertion = "verified" / "logged" / "proximity" yang$date-and-time = text .regexp cat3<"[0-9]{4}-[0-9]{2}-[0-9]{2}T", "[0-9]{2}:[0-9]{2}:[0-9]{2}([.][0-9]+)?", "(Z|[+-][0-9]{2}:[0-9]{2})"> cat3 = (A .cat B) .cat C json-binary = text .b64c T ]]>

The two examples in the RFC can be validated with this little patchup script:

RFC 9457 (Problem Details for HTTP APIs) defines a simple data model that is reproduced in CDDL here:

CDDL for RFC 9457 any } ; RECOMMENDED: absolute URI or at least absolute path: preferably-absolute-uri = ~uri ]]>

Note that also defines a CBOR-specific data model that may be useful for tunneling or problem details in Concise Problem Details.

RFC 9595 (YANG-SID) defines a data model for a "SID file" in YANG, to be transported as a YANG-JSON instance. An equivalent CDDL data model is given here:

CDDL for RFC 9595 =cat3<"(", RE, ")*"> opt=cat3<"(", RE, ")?"> cat3 = (A .cat B) .cat C id-re = "[a-zA-Z_][a-zA-Z0-9\\-_.]*" yang$yang-identifier = text .regexp id-re revision-identifier = text .regexp "[0-9]{4}-[0-9]{2}-[0-9]{2}" sid-file-version-identifier = uint .size 4 sid = text .decimal (0..0x7fffffffffffffff); uint63 as text string plus-id = Prefix .cat id-re schema-node-re = cat3, plus-id<":">, ; qualified rep .cat ; optionally opt> > > ; qualified schema-node-path = text .regexp schema-node-re dependency-revision = { module-name: yang$yang-identifier module-revision: revision-identifier } assignment-range = { entry-point: sid size: sid } item = { ? status: "stable" / "unstable" / "obsolete" ( namespace: "module" / "identity" / "feature" identifier: yang$yang-identifier // namespace: "data" identifier: schema-node-path ) sid: sid } ]]>

Your favorite RFC here...

CDDL definitions derived from IANA registries Often, CDDL models need to use numbers that have been registered as values in IANA registries. This section is intended to have one subsection for each CDDL data model presented that is derived from an existing IANA registry. As a start, it is fleshed out with one such data model. The intention is that these reference modules are update automatically (after each change of the registry or periodically, frequent enough.) Hence, this document can only present a snapshot for IANA-derived data models. The model(s) presented here clearly are in proof-of-concept stage; suggestions for improvement are very welcome.

COSE Algorithms Registry The IANA registry for COSE Algorithms is part of the IANA cose registry group . The following automatically derived model defines some 70 CDDL rules that have the name for a COSE algorithm as its rule name and the actual algorithm number as its right hand side. The additional first rule is a type choice between all these constants; this could be used in places that just have to validate the presence of a COSE algorithm number that was registered at the time the model was derived. This section does not explore potential filtering of the registry entries, e.g., by recommended status (such as leaving out deprecated entries) or by capabilities. The names given in the COSE algorithms registry are somewhat irregular and do not consider their potential use in modeling or programming languages; the automatic derivation used here turns sequences of one or more spaces and other characters that cannot be in CDDL names ([/+] here) into underscores.

CDDL for cose-algorithms Registry

IANA Considerations This document makes no requests of IANA. However, the use of IANA registries for deriving CDDL (e.g., as in ) is an active subject of discussion.

Security considerations The security considerations of , , , , and apply. This collection of CDDL models is not thought to create new security considerations. Errors in the models could -- if we knew of them, we'd fix those errors instead of explaining their security consequences in this section.

References Normative References JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. 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. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. The Concise Data Definition Language (CDDL), as defined in RFCs 8610 and 9165, provides an easy and unambiguous way to express structures for protocol messages and data formats that are represented in Concise Binary Object Representation (CBOR) or JSON. This document updates RFC 8610 by addressing related errata reports and making other small fixes for the ABNF grammar defined for CDDL. The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. The present document defines a number of control operators that were not yet ready at the time RFC 8610 was completed:.plus,.cat, and.det for the construction of constants;.abnf/.abnfb for including ABNF (RFC 5234 and RFC 7405) in CDDL specifications; and.feature for indicating the use of a non-basic feature in an instance. The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. RFCs have added to this extension point in both an application-specific and a more general way. The present document defines a number of additional generally applicable control operators for text conversion (bytes, integers, printf-style formatting, and JSON) and for an operation on text. Informative References This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs. This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax (CMS) structure. Other YANG-derived formats are possible. The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)). This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it. This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs. This document obsoletes RFC 7807. This document defines a concise "problem detail" as a way to carry machine-readable details of errors in a Representational State Transfer (REST) response to avoid the need to define new error response formats for REST APIs for constrained environments. The format is inspired by, but intended to be more concise than, the problem details for HTTP APIs defined in RFC 7807. This document defines the format of reputation response data ("reputons"), the media type for packaging it, and definition of a registry for the names of reputation applications and response sets. 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. IANA

List of Figures

:

:

:

:

Acknowledgements TBD