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

From: Barry Leiba <[email-masked]>
Date: Tue, 12 May 2020 11:30:51 -0400

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.)

— 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?

— 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”.

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

Nit: “cannot be produced”

— 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.

— 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

— 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”.

— 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.

— 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.

— 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?

— 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?

-- 
Barry

---

From: Barry Leiba <[email-masked]>
Date: Wed, 13 May 2020 14:48:29 -0400

Thanks for the quick response, Jim.  We're good with all items, but
hold off on a revised I-D until I finish the full review (tomorrow, I
expect).

> ‘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.

As I say, it's a total nit, so I'm not going to say more than this,
but a container (here, "all other cases") contains the union of what's
in it.  My shopping list includes cauliflower and spinach (not "or"),
and your vineyard grows (perhaps) Zinfandel and Pinot Noir (not "or").
And COSE_MAC is used for A and B and C, not "or", because it's used
for all of them.  Anyway, 'nuff said here.

Barry

---

From: Jim Schaad <[email-masked]>
Date: Wed, 13 May 2020 11:08:30 -0700

-----Original Message-----
From: Barry Leiba <[email-masked]> 
Sent: Tuesday, May 12, 2020 8:31 AM
To: [email-masked]
Cc: [email-masked]
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 —

[JLS] Looks good - done

— Section 4.3 —

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

[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 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 —

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

— Section 5.2 —

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 —

‘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 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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 14 May 2020 22:57:03 +0200

On 2020-05-13, at 20:08, Jim Schaad <[email-masked]> wrote:
> 
> “counter signature” or “countersignature”. 

My dictionary does not agree.

Neither does Wikipedia or Wiktionary:
https://en.wikipedia.org/wiki/Countersign_(legal)
https://en.wiktionary.org/wiki/countersignature

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Thu, 14 May 2020 14:20:12 -0700

I looked at the dictionary before making that decision.

-----Original Message-----
From: Carsten Bormann <[email-masked]> 
Sent: Thursday, May 14, 2020 1:57 PM
To: Jim Schaad <[email-masked]>
Cc: Barry Leiba <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [COSE] AD review of draft-ietf-cose-rfc8152bis-struct-08 — DIFF CHECK

Grüße, Carsten