Subject: [COSE] Roman Danyliw's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 09 Jun 2020 10:27:09 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-cose-rfc8152bis-algs-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the easy to read diff on a bis document, and for addressing the
SecDir feedback.

** Section 8.  Per “For an algorithm, the first element should always be a key
type value, but the items that are specific to a key should not be included in
the algorithm capabilities” and later “For a key, the first element should also
be a key type value” is there a reason for not making these “should” into
normative MUSTs?

** Section 8.  I would have benefited from more text to understand how to parse
a capabilities field.  IMO, it would have been helpful to say that the first
element of the array maps to the Value column of the COSE Key Type registry. 
The new Capabilities column of that corresponding entry describes the semantics
of the second array element.

**  Editorial Nits:
-- The text in the header notes this document is standards track.  However, the
datatracker and shepherd write-up note that it is informational.  I suspect it
should be fixed in this document to be informational.

-- Abstract.  Please remove the explicit references from abstract (as they are
not permitted to be there)

-- Abstraction.  Editorial.  The sentence “In this specification the
conventions …” is incomplete.

-- Section 1.  Editorial.  “Additional algorithms beyond what are in this
document are defined elsewhere”.  IMO, this sentence doesn’t appear to add
anything.  Recommend removal.

-- Section 8.  Per ”There is a presumption in the way that this is laid out is
that the algorithm identifier itself is not needed to be a part of this as it
is specified in a different location”, I had trouble following this sentence
from the previous one – what is the double reference to “this” here?

-- Section 8.3. Typo.  s/it is encodes/, they encode/

-- Section 10.2. Typo. s/rquested/requested/

---

From: Jim Schaad <[email-masked]>
Date: Tue, 9 Jun 2020 12:43:28 -0700

-----Original Message-----
From: Roman Danyliw via Datatracker <[email-masked]> 
Sent: Tuesday, June 9, 2020 10:27 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Matthew Miller <[email-masked]>; [email-masked]
Subject: Roman Danyliw's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Thanks for the easy to read diff on a bis document, and for addressing the SecDir feedback.

** Section 8.  Per “For an algorithm, the first element should always be a key type value, but the items that are specific to a key should not be included in the algorithm capabilities” and later “For a key, the first element should also be a key type value” is there a reason for not making these “should” into normative MUSTs?
[JLS] Yes, consider what the capabilities would be for a hash algorithm, it has no key so that would make the first one not a MUST.  This is advisory, after it is set then it is going to be known and not changed.  This means that all one needs to know in the end is what the sequence is.

** Section 8.  I would have benefited from more text to understand how to parse a capabilities field.  IMO, it would have been helpful to say that the first element of the array maps to the Value column of the COSE Key Type registry. 
The new Capabilities column of that corresponding entry describes the semantics of the second array element.
[JLS] Given the above do you still feel this way?

**  Editorial Nits:
-- The text in the header notes this document is standards track.  However, the datatracker and shepherd write-up note that it is informational.  I suspect it should be fixed in this document to be informational.
[JLS] The document is wrong and fixed.

-- Abstract.  Please remove the explicit references from abstract (as they are not permitted to be there)
[JLS] As I have noted elsewhere, for drafts I prefer this to make sure that it is seen by the RFC Editor and corrected.

-- Abstraction.  Editorial.  The sentence “In this specification the conventions …” is incomplete.
[JLS] Changed to "This specification defines the conventions for the use of a number of cryptographic algorithms with COSE."

-- Section 1.  Editorial.  “Additional algorithms beyond what are in this document are defined elsewhere”.  IMO, this sentence doesn’t appear to add anything.  Recommend removal.
[JLS] Done - I guess the word 'initial' makes the point that other can be defined. 

-- Section 8.  Per ”There is a presumption in the way that this is laid out is that the algorithm identifier itself is not needed to be a part of this as it is specified in a different location”, I had trouble following this sentence from the previous one – what is the double reference to “this” here?
[JLS] How about "The algorithm identifier is not included in the capabilities data as it should be encoded elsewhere in the message."

[JLS] Already rewritten

[JLS] Fixed.