[Gen-art] Genart last call review of draft-ietf-cose-rfc8152bis-struct-09

[Theresa Enghardt via Datatracker <[e-mail]>]

Reviewer: Theresa Enghardt
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-cose-rfc8152bis-struct-09
Reviewer: Theresa Enghardt
Review Date: 2020-05-25
IETF LC End Date: 2020-05-29
IESG Telechat date: Not scheduled for a telechat

Summary: This document describes data structures and processes in detail, with
minor updates. In combination with a companion document on algorithms, it
obsoletes RFC 8152. The document has some issues and editorial nits, which
should be addressed prior to publication.

Major issues:

The intended RFC status is Internet Standard, while RFC 8152 is a Proposed
Standard. While this document points to three different implementations, how
widespread is their deployment? Were there other lessons learned from
implementation and deployment experience? Has complexity been reduced by
removing unused features, as RFC 6410 suggests?

Minor issues:

In the introduction, it would be great to add some more context on how COSE is
intended to be used. Is this solely for adding security to objects within CoAP,
e.g., by signing and encrypting messages exchanged as CoAP payload? Or can it
be used with other protocols or in other contexts? In RFC 7165, which describes
JOSE use cases, Section 5.8.2 mentions Object Security for CoAP. Is COSE
addressing this use case? If so, please add a link to Section 5.8.2 of RFC
7165. Section 9.5.4 mentions that COSE "is designed for a store and forward
environment rather than an online environment". Perhaps it's worth mentioning
such design goals and context in the introduction already. When adding one or
two paragraphs on how COSE is intended to be used to the introduction, it's
also worth stating explicitly that each application is expected to select the
COSE objects and processes that it needs, and that Section 11 provides more
guidance on how to do this. This will make it easier for application developers
to understand how to use COSE.

"One feature that is present in CMS [RFC5652] that is not present in
   this standard is a digest structure.  This omission is deliberate.
   It is better for the structure to be defined in each document as
   different protocols will want to include a different set of fields as
   part of the structure."
Does "in each document" refer to documents for different encryption algorithms
or protocols? Please clarify. Is draft-ietf-cose-rfc8152bis-algs an example of
one of these documents, as it describes algorithms? Or is another type of
documents meant here?

When introducing the CDDL syntaxes:
Is "* label => values" missing here? It appears to be used in some examples
below.

"The CDDL grammar is informational; the prose
   description is normative."
Why? Isn't it important for interoperability that the objects are structured in
a certain way and that there is no ambiguity?

In Section 2:
"[...] The wrapping allows for the encoding of the
  protected map to be transported with a greater chance that it will
  not be altered in transit.  (Badly behaved intermediates could
  decode and re-encode, but this will result in a failure to verify
  unless the re-encoded byte string is identical to the decoded byte
  string.)  This avoids the problem of all parties needing to be
  able to do a common canonical encoding."
I'm not sure I understand this scenario. Does this statement just apply to
zero-length maps or to all kinds of protected buckets? What does "to be
transported with a greater chance" mean here? That intermediates are less
likely to block traffic containing such a COSE object? That intermediates are
less likely to accidentally (or deliberately) modify it in such a way that it
gets accepted by the receiver? Is this an effect of some cryptographic
protection, is it related to different encoding techniques being used in
different implementations, or both? Why is it a problem if all parties need to
be able to do a common canonical encoding? In fact, what kind of encoding does
this refer to: Binary encoding vs. base64 encoding? Or specific ways of
encoding certain information as binary data?

In Section 4.1:
"An example of
   header a parameter about the content is the content type. "
This sentence appears to be broken.

In Section 4 or 5, maybe it's worth adding a brief description or reference of
what a countersignature is. In contrast to the concepts of signing, encryption,
and Message Authentication Codes, I would not expect every application
developer to be familiar with the concept of a countersignature and what it's
needed for.

In Section 10, the document presents restrictions on the CBOR encoder.
"We have managed to narrow it down to the following restrictions" sounds like
these might have been narrowed down from RFC 8152, and maybe could be rephrased
to sound more neutral. Why are these restrictions necessary? Maybe it's worth
adding a brief explanation for each restriction.

In the Security Considerations:
What threat models have been considered for COSE?

Nits/editorial comments:

Section 12:
"The only known action at this time
   is to update the references."
Right after this statement, the document describes another IANA action. So
maybe updating the references is not "the only known action" anymore?

For most IANA registries, this document simply asks to update the references
from RFC 8152 to this document. However, for the Media Type Registrations,
Section 12.5 appears to repeat the registry information. Does this document
introduce any changes here? If not, why is the information repeated here, but
not in the other sections?