Subject: [COSE] 🔔 WGLC of rfc8152bis drafts (-struct and -algs)

From: "Matthew A. Miller" <[email-masked]>
Date: Mon, 29 Jul 2019 09:21:46 -0600

This message starts the Working Group Last Call on the two 8152bis drafts:

* draft-ietf-cose-rfc8152bis-struct [COSE-STRUCT] (Structures and Processes)
* draft-ietf-cose-rfc8152bis-algs [COSE-ALGS] (Algorithms)

The working group last call with run for **four weeks**, ending on
August 26, 2019.

Please review and send any comments or feedback to the working group.
Even if your feedback is "this is ready", please let us know.

Thank you,

- Ivaylo and Matthew
COSE Chairs

[COSE-STRUCT]: <
https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/ >
[COSE-ALGS]: <
https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ >

---

From: "Matthew A. Miller" <[email-masked]>
Date: Tue, 30 Jul 2019 10:16:40 -0600

[ Posting as an individual ]

This is my review of draft-ietf-cose-rfc8152bis-struct.  Overall I think
the document is nearly ready, with what I consider editorial issues
(some larger than others) that ought to be addressed one way or another.

I note that I have not tried to verify the examples in
-rfc8152bis-struct, though the diagnostic values all seem correct to me
(where a visual inspection is possible).

Thank you again, Jim, for undertaking this document.

## Minor Questions/Concerns ##

* The term "context" is used throughout as an information set and/or
configuration not discretely encoded in the protocol, but is never
explicitly defined.  I think it important to define, especially as
abbreviated counter signatures wholly depend on inferred parameters.

* Further with abbreviated counter signatures, I think the original text
in RFC 8152 Appendix A.2 did a bit better to be explicit on what was
implicit, and that CounterSignature0 applied to more than encrypted
data.  I suggest rewording the first paragraph to something like the
following:

"""
   Abbreviated countersignatures were designed primarily to deal with
   the problem of having group encrypted messaging, but still needing to
   know who originated the message.  The object was to keep the
   countersignature as small as possible while still providing the
   needed security.  For abbreviated countersignatures, there is no
   provision for any protected attributes related to the signing
   operation.  Instead, the parameters for computing or verifying the
   abbreviated countersignature are inferred from the same context used
   to describe the encryption, signature, or MAC processing.
"""

* The sections that describe generically describe algorithm classes
(Sections 9 through 13), to me, break with the flow of the document and
can seem to imply the actual algorithms are still defined herein.  I
think it would be worth making them all subsections under a "Algorithm
Classes in Use" (or a better title), with a short paragraph stating the
following describe categories of algorithms and the requirements or
restrictions placed on algorithms that apply.

## Nits ##

* The reference to I-D.ietf-cbor-cddl should be updated to RFC 8610.

* In Section 1.2 "Changes from RFC8152", "standalong" should be
"standalone".

* Table 2 ought to be explicitly changed to`[[ this document ]]` to aid
the RFC Editor.

* In Section 4.4 "Signing and Verification Process", the CDDL for
`Sig_structure` is missing "CounterSignature0" as an option for `context`.

* In Section 5 "Counter Signatures", paragraph 2, the word "oppose"
should be "opposed" in the sentence "It should be noted as oppose to
attesting to the unencrypted data."

* In Section 5.2 "Abbreviated Countersignatures", first paragraph,
"orginated" should be "originated".

* In Section 6.1.1 "Content Key Distribution Methods", the "key
transport" and "passwords" entries have a note on "[no] algorithms are
defined in this document".  I think it enough to strike this last
sentence completely from each, but can see a case for saying "[no]
algorithms are defined in [I-D.ietf-cose-rfc8152bis-algs]" instead.

* In Section 10 "Message Authentication Code (MAC) Algorithms", the
penultimate paragraph should have "this document" replaced with a
reference to draft-ietf-cose-rfc8152bis-algs.

* In Section 14 "CBOR Encoding Restrictions", the second bullet's first
sentence seems to be missing a word or two; suggest changing to
something like:

  """
  Encoding MUST be done using definite lengths and values MUST be
encoded using the minimum possible length.
  """

* In Section 15 "Application Profiling Considerations", the word
"profiles" should be "profile" in second paragraph ("... where a
profiles was developed for ...").

* In Section 17 "Security Considerations", the third bulleted item
should have a reference to draft-ietf-cose-rfc8152bis-algs instead of
this document ("Several algorithms in this document ...").

* Also in Section 17 "Security Considerations", the penultimate
paragraph mentions that "algorithms presented in this document"; "this
document" should be replaced with a reference to
draft-ietf-cose-rfc8152bis-algs.

* In Section 18.1 "Author's Versions", "THe" should be "The".

* The title for Section 18.2 should be "JavaScript Version".

* In Appendix A "Guidelines for External Data Authentication of
Algorithms", the second bulleted item should have "algorithms in this
document" changed to reference draft-ietf-cose-rfc8152bis-algs.

- m&m

Matthew A. Miller

---

From: Jim Schaad <[email-masked]>
Date: Wed, 31 Jul 2019 11:02:49 -0700

Comments inline.

-----Original Message-----
From: COSE <[email-masked]> On Behalf Of Matthew A. Miller
Sent: Tuesday, July 30, 2019 9:17 AM
To: cose <[email-masked]>
Subject: [COSE] Review of draft-ietf-cose-rfc8152bis-struct for 🔔 WGLC of rfc8152bis drafts

This is my review of draft-ietf-cose-rfc8152bis-struct.  Overall I think the document is nearly ready, with what I consider editorial issues (some larger than others) that ought to be addressed one way or another.

I note that I have not tried to verify the examples in -rfc8152bis-struct, though the diagnostic values all seem correct to me (where a visual inspection is possible).

[JLS] The good news is that as long as I do not touch them, the examples were pulled directly from the examples website as they were automatically generated for RFC 8152.

* The term "context" is used throughout as an information set and/or configuration not discretely encoded in the protocol, but is never explicitly defined.  I think it important to define, especially as abbreviated counter signatures wholly depend on inferred parameters.

[JLS] Proposed text:

          Context is used throughout the document to represent information that is not part of the COSE message.
          Information which is part of the context can come from several different sources including:
          Protocol interactions, associated key structures and program configuration.
          Context should generally be included in the cryptographic configuration, for more details see <xref target="Extern_AAD"/>.

* Further with abbreviated counter signatures, I think the original text in RFC 8152 Appendix A.2 did a bit better to be explicit on what was implicit, and that CounterSignature0 applied to more than encrypted data.  I suggest rewording the first paragraph to something like the
following:

"""

[JLS] Looks good - done.

* The sections that describe generically describe algorithm classes (Sections 9 through 13), to me, break with the flow of the document and can seem to imply the actual algorithms are still defined herein.  I think it would be worth making them all subsections under a "Algorithm Classes in Use" (or a better title), with a short paragraph stating the following describe categories of algorithms and the requirements or restrictions placed on algorithms that apply.

[JLS] This makes a good deal of sense to me.  Even if it means that I need to go and refresh all of the references in other documents.  For now I have used the section title "Taxonomy of Algorithms used by COSE" although Classification might be a less esoteric term.  Text for the section is currently

      <t>
        In this section, a taxonomy of the different algorithm types that can be used in COSE is laid out.
        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.
      </t>

## Nits ##

[JLS] Done

* In Section 1.2 "Changes from RFC8152", "standalong" should be "standalone".
[JLS] Done.

* Table 2 ought to be explicitly changed to`[[ this document ]]` to aid the RFC Editor.
[JLS] Done.

* In Section 4.4 "Signing and Verification Process", the CDDL for `Sig_structure` is missing "CounterSignature0" as an option for `context`.
[JLS] Done.

* In Section 5 "Counter Signatures", paragraph 2, the word "oppose"
should be "opposed" in the sentence "It should be noted as oppose to attesting to the unencrypted data."
[JLS] Done.

* In Section 5.2 "Abbreviated Countersignatures", first paragraph, "orginated" should be "originated".
[JLS} Done

* In Section 6.1.1 "Content Key Distribution Methods", the "key transport" and "passwords" entries have a note on "[no] algorithms are defined in this document".  I think it enough to strike this last sentence completely from each, but can see a case for saying "[no] algorithms are defined in [I-D.ietf-cose-rfc8152bis-algs]" instead.
[JLS] Eliminated for key transport, since RSA algorithms now exist.  Changed the language on passwords to " As of when this document was published, no password algorithms have been defined."

* In Section 10 "Message Authentication Code (MAC) Algorithms", the penultimate paragraph should have "this document" replaced with a reference to draft-ietf-cose-rfc8152bis-algs.
[JLS] Done

* In Section 14 "CBOR Encoding Restrictions", the second bullet's first sentence seems to be missing a word or two; suggest changing to something like:

  """
  Encoding MUST be done using definite lengths and values MUST be encoded using the minimum possible length.
  """
[JLS] Done

* In Section 15 "Application Profiling Considerations", the word "profiles" should be "profile" in second paragraph ("... where a profiles was developed for ...").
[JLS] Switched /a profiles/one/

* In Section 17 "Security Considerations", the third bulleted item should have a reference to draft-ietf-cose-rfc8152bis-algs instead of this document ("Several algorithms in this document ...").
[JLS] Done

* Also in Section 17 "Security Considerations", the penultimate paragraph mentions that "algorithms presented in this document"; "this document" should be replaced with a reference to draft-ietf-cose-rfc8152bis-algs.
[JLS] Done.   This has been frequently enough in the review that I did a scan for the phrase "this document" and fixed a couple of other cases.

* In Section 18.1 "Author's Versions", "THe" should be "The".
[JLS] This section disappears before publication, but fixed it anyway.

[JLS] Done

* In Appendix A "Guidelines for External Data Authentication of Algorithms", the second bulleted item should have "algorithms in this document" changed to reference draft-ietf-cose-rfc8152bis-algs.
[JLS]

- m&m

Matthew A. Miller
> https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ >

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