Re: [COSE] AD review of draft-ietf-cose-rfc8152bis-struct-08 — DIFF CHECK

[Jim Schaad <[e-mail]>]

-----Original Message-----
From: Barry Leiba <[e-mail]> 
Sent: Tuesday, May 12, 2020 8:31 AM
To: [e-mail]
Cc: [e-mail]
Subject: AD review of draft-ietf-cose-rfc8152bis-struct-08 — DIFF CHECK

Hi, all.  I've picked up the sponsorship of the two 8152bis drafts from Ben in order to help share the load and get the documents moving faster than Ben has time for just now.

I've started AD review with a pass at the diffs between this document and 8152; I will follow with a closer review of this document to see if there are things that look like they should have been updated or clarified, but weren't (I don't expect to find much there, but I want to look).  Here's the review of the diffs:

Please be consistent about use of “counter signature” or “countersignature”.  Consider, for example, the inconsistency in the 4th and 5th paragraphs of Section 5.1, and the section title of 5 vs
5.1 and 5.2.  (It looks like 8152 spelled it as two words and 8152bis spells it as one.  I don't care which way the WG wants to go for the update, but it should be consistent throughout the document.)
[JLS] Given that 8152 used two words, I made a pass to make it two words here as well.

— Section 3 —

      the value is wrapped in the binary object.  Recipients MUST accept
      both a zero-length binary value and a zero-length map encoded in

Should this say “zero-length byte string” for consistency?
[JLS] Looks good - done

— Section 4.3 —

   proxy, or an attacker, changes the set of accept values by including
   the field in the application supplied data.

Nit: hyphenate “application-supplied”.
[JLS] look fine - done twice

   *  If multiple items are included, applications need to ensure that
      the same byte string cannot produced if there are different

Nit: “cannot be produced”
[JLS] looks fine - done

— Sections 4.4, 6.3, and 7.3 —
In bullets 2 and 3 in each, I think it’d be better to use “zero-length byte string” for consistency in the text, rather than “bstr of length zero” or “zero-length bstr” sometimes.
[JLS] I don't feel strongly about this - done

— Section 5 —

   It is always possible to construct cases
   where the decryption is successful, while providing completely
   different answers by using a different key.  This situation is not
   detectable by a countersignature on the encrypted data.

It took me a few readings of this to get what I think you mean.  I don’t think I would refer to this as “the decryption is successful.”
Might this be better said with something like this?:

NEW
It is always possible to construct cases where use of a different key appears to result in successful decryption, but provides completely different unencrypted data.  This situation is not detectable by a countersignature on the encrypted data.
END

[JLS] How about

It is always possible to construct cases where the use of two different keys will appear to result in a successful decryption (the tag check success), but which produce two completely different plaintexts.  This situation is not detectable by a counter signature on the encrypted data.

— Section 5.1 —

   The full countersignature structure can be encoded as either a tagged
   or untagged depending on the context it is used in.

Nit: remove “a”.
[JLS] Fine - done

— Section 5.2 —

   Abbreviated countersignatures were designed primarily to deal with
   the problem of having group encrypted messaging

Would “encrypted group messaging” be better?  The MLS working group refers to "group messaging", and we're talking about making that encrypted.
[JLS] Core documents appear to use "secure group communication", but I think that this change is still clear.  done

— Section 7 —

   COSE_MAC is used for all other cases.  These
   include a requirement for multiple recipients, the key being unknown,
   or a recipient algorithm of other than direct.

‘Tis a total nit, but you changed “and” to “or” here, and I think the change was incorrect, and the original “and” was correct — the “other cases” include all three of the examples.
[JLS] This change was made in response to a WG comment.  I believe that "or" is correct here as there are three different cases being listed rather than a combination of the three cases.

— Section 9 —

   This taxonomy should not be considered
   to be exhaustive as there are new algorithm structures that could be
   found or are not known to the author.

This reads oddly to me: “that could be found” seems strange, and “not known to the author” feels wrong in a working group document.  Can you try rewording this?
[JLS]  Does this seem better?
        In this section, a taxonomy of the different algorithm types that can be used in COSE is laid out.
        This taxonomy should not be considered to be exhaustive.
        New algorithms will be created which will not fit into this taxonomy.
        If this occurs, then new documents addressing this new algorithms are going to be needed.


— Section 9.5.1 —
Should either or both instances of “zero-length item” here be “zero-length byte string” or “zero-length text string” so as to be appropriately specific?
[JLS] Yes they should - done.


Jim

--
Barry