Shepherd writeup
rfc8152-24

1. Summary

The document shepherd is Göran Selander. The responsible Area Director is Kathleen Moriarty.

This specification describes how to create and process signatures, message authentication codes and encryption using the Concise Binary Object Representation (CBOR, RFC7049) for serialization.  The specification additionally specifies how to represent cryptographic keys using CBOR.

This specification is a Standards Track RFC describing a solution component analogous to the JSON Web suite of security RFCs 7515-7518 (JOSE WG), but using the CBOR encoding format.


2. Review and Consensus

The document was developed by the COSE working group based on requirements from constrained device/IoT community (CORE/ACE WGs) and on the experience of developing the JSON Web security suite of RFCs (JOSE/OAuth WGs). There is a small dedicated team of people interested in this work, and reviews has been performed mainly by these people. One category of issues has been on generic message format vs dedicated formats optimized for certain constrained settings. This was resolved with a small set of dedicated formats complementing the generic formats. Another category of issues has been on the deviations from JOSE or omission of legacy crypto not suitable for constrained devices. There has been some contention by individuals of how individual review comments were addressed. There are no substained objections on any issues relating to this draft. The current open issues are related to additional algorithm and is out of scope for this draft. There has not yet been any dedicated full security review of this version of the draft.

The draft records the status of known implementations of the protocol defined by this specification (based on RFC 7942). Three implementations currently maintained by the author are referenced, in Java, C# and C (https://github.com/cose-wg).
Ongoing work on a JavaScript implementation has been announced. Implementations optimized for constrained platforms are requested by different companies and is in progress.

3. Intellectual Property

The author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document:

https://www.ietf.org/mail-archive/web/cose/current/msg01106.html

4. Other points

* The IANA considerations section asks for registration into existing registries:

16.1.  CBOR Tag assignment

Request for tags in range 0-23 requires standards action. Requesting tags in this range is is well founded since the objective for these registrations is to produce as compact message format as possible. Request for assignment in range 24-255 requires specification which is provided by this draft. It would be beneficial to request early assignment of the requested CBOR Tags to include in the RFC. The author is has contacted the expert on this.

16.9.  Media Type Registrations

Two new media types needs to be registered for the formats specfied in the draft.

Clarification of what "RFC TBD" is referencing needs to be added (4 occurances).


16.10.  CoAP Content Format Registrations

Assignment in the 24-255 range as requested requires Expert Review.


* The IANA considerations also request for a set of new registries to be created. One of the objectives of this work is to create a compact protected message format and one part of achieving that is to label various message parameters. Expert review is required for all these registrations and instructions are provided. References to tables with initial contents is provided. The new registries requested are:

16.2.  COSE Header Parameters Registry  

16.3.  COSE Header Algorithm Parameters Registry

16.4.  COSE Algorithms Registry

Editorial: The references to tables with initial contents of the registry is unordered.

16.5.  COSE Key Common Parameters Registry

16.6.  COSE Key Type Parameters Registry

16.7.  COSE Key Type Registry

16.8.  COSE Elliptic Curve Parameters Registry


* The Id-nits are essentially remarks on references:

" -- Possible downref: Non-RFC (?) normative reference: ref. 'AES-GCM'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'MAC'

  ** Downref: Normative reference to an Informational RFC: RFC 2104

  ** Downref: Normative reference to an Informational RFC: RFC 3394

  ** Downref: Normative reference to an Informational RFC: RFC 3610

  ** Downref: Normative reference to an Informational RFC: RFC 5869

  ** Downref: Normative reference to an Informational RFC: RFC 6090

  ** Downref: Normative reference to an Informational RFC: RFC 7539

  -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1'

  -- Obsolete informational reference (is this intentional?): RFC 2633
     (Obsoleted by RFC 3851)"

The downreferences are references to crypto algorithms which are normatively used in the draft so is correct. Referencing RFC 2633 is intentional for addressing older versions of S/MIME; and actually RFC 5751, which is the RFC obsoleting RFC 3851, is referenced in the draft.

* Appendix C contains a substantial number of examples. There is a GitHub project referenced
(https://github.com/cose-wg/Examples) which contains a superset of the examples in the draft including the JSON input used in the examples.
Back