Comments inline.
-----Original Message-----
From: COSE <[email protected]> On Behalf Of Matthew A. Miller
Sent: Tuesday, July 30, 2019 9:17 AM
To: cose <[email protected]>
Subject: [COSE] Review of draft-ietf-cose-rfc8152bis-struct for 🔔 WGLC of
rfc8152bis drafts
[ 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).
[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.
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.
[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:
"""
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.
"""
[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 ##
* The reference to I-D.ietf-cbor-cddl should be updated to RFC 8610.
[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.
* The title for Section 18.2 should be "JavaScript Version".
[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
On 19/07/29 11:21, Matthew A. Miller wrote:
> 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/ >
>
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
