]> COSE: On Registration Principles Universität Bremen TZI
Postfach 330440 Bremen D-28359 Germany +49-421-218-63921 cabo@tzi.org
Security CBOR Object Signing and Encryption COSE (STD 96, RFC 9052 and RFC 9338) defines a number of registries that allow registrants to exercise the numerous extension points defined in COSE. Section 11.6 of RFC 9052 gives the Designated Experts for these registries considerable leeway in deciding about registration requests. The present document is intended to collect information that has been the basis for initial population of and further registration in these registries. It is intended to be shaped by the Designated Experts and serve them as a collective memorandum and a checklist. As a secondary function, it is also intended to help registrants create registrations that are acceptable to the Designated Experts. Revision -00 of this draft is an early skeleton that should allow us to decide whether such a collection of information is useful and whether we want to flesh out this document. About This Document Status information for this document may be found at . Discussion of this document takes place on the CBOR Object Signing and Encryption (COSE) Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .
Introduction COSE (STD 96, RFC 9052 and RFC 9338) defines a number of registries that allow registrants to exercise the numerous extension points defined in COSE. Section 11.6 of RFC 9052 gives the Designated Experts for these registries considerable leeway in deciding about registration requests. Specifically, says:
11.6. Expert Review Instructions All the IANA registries established by are, at least in part, defined as Expert Review . This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason, so they should be given substantial latitude.
( is the previous edition of what is now and ; this document established the registries being discussed, which together make up the registry group.) The further text of gives instructions about the general operations of the registries, but does not discuss the architectural and structural principles that might go into a registration decision. The present document is intended to collect information that has been the basis for initial population of and further registration in these registries. It is intended to be shaped by the Designated Experts and serve them as a collective memorandum and a checklist. As a secondary function, it is also intended to help registrants create registrations that are acceptable to the Designated Experts. Revision -00 of this draft is an early skeleton that should allow us to decide whether such a collection of information is useful and whether we want to flesh out this document.
Conventions and Definitions The definitions of and apply.
COSE Registration Principles This section is a skeleton and needs to be fleshed out. At the time of writing, some 172 registrations have been made in the COSE registry group . These can serve as a body of examples how to make registrations. Unfortunately, not all registrations in this set demonstrate outstanding consistency in decision-making, so this section will also collect information about where existing registration decisions turned out to be suboptimal or at least different in structure than registrations of a similar nature.
General Considerations
Code Point Frugality:
COSE is designed to work in environments where at least some of the devices have limited resources; curation of codepoints so that the ones that are most frequently used with such constrained devices receive the codepoints with the shortest representation (and can continue to do so over a number of decades) is always an objective.
COSE Header Parameters ...
COSE Header Algorithm Parameters ...
COSE Algorithms Algorithm identifiers in these registrations have a Recommended Tag, which indicates ():
Recommended:
Does the IETF have a consensus recommendation to use the algorithm? The legal values are 'Yes', 'No', and 'Deprecated'.
Note that an algorithm can be deprecated already at registration time. This value was used in the registration of the values which only can be used under very specific conditions. Algorithm identifiers are usually assigned so that a single identifier stands for a collection of underlying algorithms, with main parameters such as key or hash length chosen, so that a single algorithm identifier suffices to fully characterize the cryptographic operations. A key is the obvious exception, but also parameters that go with a key such as its curve type. Where a certain underlying algorithm has a small number of possible parameter sets, all registrations for the use of that underlying algorithm in a COSE Algorithm are made at the same time. For instance: A128GCM (AES-GCM mode w/ 128-bit key, 128-bit tag) we registered together with A192GCM (AES-GCM mode w/ 192-bit key, 128-bit tag) and A256GCM (AES-GCM mode w/ 256-bit key, 128-bit tag). The expert (in this case the author of ) did not make separate assessments how useful or desirable the individual parameter sets were going to be, but registered them all at once. When the collection of AES-CCM-16-64-128, AES-CCM-16-64-256, AES-CCM-64-64-128, and AES-CCM-64-64-256, as well as AES-CCM-16-128-128, AES-CCM-16-128-256, AES-CCM-64-128-128, and AES-CCM-64-128-256 were registered, these were also registered all at once, but grouped into two groups with different representation sizes of the algorithm identifier.
COSE Key Common Parameters ...
COSE Key Type Parameters ...
COSE Key Types ...
COSE Elliptic Curves This registry is governed by similar principles as the COSE Algorithms registry (). Curve types identify all parameters of a curve and are registered all at once where natural groups of such types exist.
Security Considerations This document is about registrations in registries that have direct security impact; security considerations that require discussion beyond that are mentioned in the discussions above.
IANA Considerations This document has no IANA actions.
Informative References CBOR Object Signing and Encryption (COSE): Structures and Process 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. CBOR Object Signing and Encryption (COSE): Countersignatures 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. Concise Binary Object Representation (CBOR) 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. CBOR Object Signing and Encryption (COSE) IANA Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. CBOR Object Signing and Encryption (COSE) Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined 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. CBOR Object Signing and Encryption (COSE): Initial Algorithms 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 a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. CBOR Object Signing and Encryption (COSE): AES-CTR and AES-CBC Vigil Security, LLC Arm Limited The Concise Binary Object Representation (CBOR) data format is designed for small code size and small message size. CBOR Object Signing and Encryption (COSE) is specified in RFC 9052 to provide basic security services using the CBOR data format. This document specifies the conventions for using AES-CTR and AES-CBC as Content Encryption algorithms with COSE.
Acknowledgments This document was motivated by a discussion at IETF 117 Hackathon. The author is grateful to the many contributors to the discussions on the mailing lists that build the basis for this document.