-----Original Message-----
From: COSE <[email protected]> On Behalf Of John Mattsson
Sent: Thursday, November 21, 2019 2:27 PM
To: [email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/cose
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
