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

From: John Mattsson <[email-masked]>
Date: Thu, 21 Nov 2019 22:27:13 +0000

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?

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

- "strings" are used in in various places. Should be changed to "byte string" or "text string" as CBOR has two types of strings

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

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

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

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

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

- "digesst"
- "stucture"

draft-ietf-cose-rfc8152bis-algs-06

- "the the"

Cheers,
John

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 22 Nov 2019 06:39:44 +0800

> Could we replace "data origination" with "non-repudiation"?

Preferably not.

If you want the thing that often is identified incorrectly by the latter, please use a more precise term such as “third party verifiability”.  Non-repudation is a legal term.

Provenance is often a term used for the former.

BTW, the text might be easier to read when constructs such as “bistro”, oops, “bstr”, are replaced by “byte string” outside of the CDDL (where byte strings are indeed called “buster”, oops, “bstr”, or also simply “bytes”).  In the previous sentence, for demonstration, I left in the autocorrects as they actually happened :-)

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Fri, 22 Nov 2019 09:28:53 +0800

-----Original Message-----
From: COSE <[email-masked]> On Behalf Of Carsten Bormann
Sent: Friday, November 22, 2019 6:40 AM
To: John Mattsson <john.mattsson=[email-masked]>
Cc: [email-masked]
Subject: Re: [COSE] Comments on draft-ietf-cose-rfc8152bis-struct-07 and draft-ietf-cose-rfc8152bis-algs-06

> Could we replace "data origination" with "non-repudiation"?

Preferably not.
[JLS]  No really, really not.

If you want the thing that often is identified incorrectly by the latter, please use a more precise term such as “third party verifiability”.  Non-repudation is a legal term.
[JLS] Non-repudiation is not a legal term.  Repudiation is a legal term.  There is no such thing as non-repudiation, just a legal argument that you can or cannot repudiate something.   I repudiate this signature because Carsten was holding a gun to my head when I made it.  That is a repudiate argument and not the reverse.  Non-repudiation originally had some really weird ideas around having a technological way of proving things like:  It was proven that the key was in my possession. It was proven that only I could have made the signature.  I knew what I was signing a the time.   That is things that cannot be shown.

Jim

Grüße, Carsten

_______________________________________________
COSE mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cose

---

From: John Mattsson <[email-masked]>
Date: Tue, 26 Nov 2019 10:18:42 +0000

“third party verifiability” would be good. In the current text, I do not understand what the four "data origination"/"weak data origination" sentences want to say except “third party verifiability” "and data authentication". 

   "Message Authentication Codes (MACs) provide data authentication and
   integrity protection.  They provide either no or very limited data
   origination.  A MAC, for example, cannot be used to prove the
   identity of the sender to a third party."

    "They provide
     integrity on the data that was encrypted; however, they provide
     either no or very limited data origination.  (One cannot, for
     example, be used to prove the identity of the sender to a third
     party.)  The ability to provide data origination is linked to how the
     CEK is obtained."

   "The use of key wrap loses the
     weak data origination that is provided by the direct encryption
     algorithms."

   "The use of static keys allows for the
     recipient to get a weak version of data origination for the
     message."

/John

-----Original Message-----
From: Jim Schaad <[email-masked]>
Date: Friday, 22 November 2019 at 02:29
To: 'Carsten Bormann' <[email-masked]>, John Mattsson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [COSE] Comments on draft-ietf-cose-rfc8152bis-struct-07 and draft-ietf-cose-rfc8152bis-algs-06

    -----Original Message-----
    From: COSE <[email-masked]> On Behalf Of Carsten Bormann
    Sent: Friday, November 22, 2019 6:40 AM
    To: John Mattsson <john.mattsson=[email-masked]>
    Cc: [email-masked]
    Subject: Re: [COSE] Comments on draft-ietf-cose-rfc8152bis-struct-07 and draft-ietf-cose-rfc8152bis-algs-06

    Preferably not.

    Jim

    
    Grüße, Carsten