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
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
