Re: [COSE] Comments on draft-ietf-cose-rfc8152bis-struct-07 and draft-ietf-cose-rfc8152bis-algs-06

-----Original Message-----
From: COSE <cose-bounces@ietf.org> On Behalf Of John Mattsson
Sent: Thursday, November 21, 2019 2:27 PM
To: cose@ietf.org
Subject: [COSE] Comments on draft-ietf-cose-rfc8152bis-struct-07 and draft-ietf-cose-rfc8152bis-algs-06

Comments on draft-ietf-cose-rfc8152bis-struct-07 and draft-ietf-cose-rfc8152bis-algs-06

General:

 - Minor note: The abstracts of the documents have minor differences and the subsections in the introductions have differ orders.

 - As RFC 8610 is published now, shouldn’t the documents be updated to match the final CDDL grammar?

[JLS] As far as I know, the grammar does match what is in RFC 8610.  What I wanted to avoid was a normative dependency on that document.

draft-ietf-cose-rfc8152bis-struct-07:

 - "There has been an increased focus on small, constrained devices"

   I think the document should mention constrained radio technologies as well

[JLS] I don't see the point to that.  This is a small throw away line to help provide motivation.  Adding a duplicate of the same case does not seem to provide any benefits. 

- "strings" are used in in various places. Should be changed to "byte string" or "text string" as CBOR has two types of strings.  I have added a line to the document terminology section.

[JLS] I just went through the document again and made sure that I was consistent.  I am always using either "byte string" or "string".  The latter is used for text strings.  I am not sure that 

- "3.  The content of the message.  The content is either the plaintext or the ciphertext as appropriate."

  This seems to only describe encryption. For signatures and MACs it would be payload, signature/tag.

[JLS]  I would be willing to change plaintext to a different term, but payload is way to overloaded to be placed there.  While plaintext is used in the context of encryption, it is still meaningful here as being something that is not the ciphertext and thus is the original text.  As such it is not inappropriate for signed and mac-ed contexts.

- "structure", "message", "object", "map", "array", "object structure", "message structure", "data object", "structure object", "map object", "array object", "data structure", "data item", "CBOR structures", "COSE structure", "COSE map", "CBOR map", "CBOR object", "COSE object"

  There is a large amount of terms used in the documents. I feel that they could be defined a bit more. Also, are all of them really needed?
[JLS] I cleaned some of these out.

- OLD "The set of protected header parameters wrapped in a bstr."
  NEW "The set of protected header parameters as a map wrapped in a bstr."

[JLS] I went with a slightly different wording.

- The draft has quite a lot of text on different types of signatures like signatures with message recovery. Would be good to have some sentences on signatures with and without state. The text on signatures is also missing that they provide data authentication, integrity protection, and provides non-repudiation.

[JLS] I don't see that information on stateful signatures is going to be relevant here.  A stateful signature algorithm does not change how any of the encoding/decoding of COSE is done. The only reason why I put in the text about message recovery signatures is that this affects how the code is written when one of these shows up and knowing in advance that it may be a problem is useful.

[JLS] Added some text on Data Origination and Data integrity.  As previously discussed, non-repudiation is a made up term with no meaning.

- "They provide either no or very limited data origination."
  This sentence occurs in several places. The term "data origination" seems to not be used very much and also have different meanings.
  E.g. the book "Information Security:   Dictionary of Concepts, Standards and Terms" defines it as
     "data origination. In computing, the translation of information from its original form into machine readable form or directly into electrical signals."

Could we replace "data origination" with "non-repudiation"?
[JLS] from RFC 4949

$ data origin authentication service
      (I) A security service that verifies the identity of a system
      entity that is claimed to be the original source of received data.
      (See: authentication, authentication service.)

Jim

- "digesst"
- "stucture"

draft-ietf-cose-rfc8152bis-algs-06

- "the the"

Cheers,
John

_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose