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.