-----Original Message-----
From: Barry Leiba <[email protected]>
Sent: Tuesday, May 12, 2020 8:31 AM
To: [email protected]
Cc: [email protected]
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
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
