Authors,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the source file.
1) <!--[rfced] Please note that the title of the document has been
updated as follows:
a) The abbreviation "RATS" has been expanded per Section 3.6 of RFC
7322 ("RFC Style Guide"). Please review.
b) We have changed "Messages" to "Message" in the expansion of CMW to
match other uses in the document.
Original:
RATS Conceptual Messages Wrapper (CMW)
Current:
Remote ATtestation procedureS (RATS) Conceptual Message Wrapper (CMW)
-->
2) <!--[rfced] We wanted to check back regarding the following response
from the Document Intake form:
"Dionna Glaze is no longer employed by Google. I chatted with her last
week, and she told me that she is currently negotiating with her
employer to be listed as an author/contributor. Depending on the
outcome of these negotiations, she may need to be moved to the
Acknowledgements section. Hopefully, we'll only need to update her
email address."
Please let us know if/how to update. -->
3) <!--[rfced] To what does "This" refer in the following text?
Original:
This allows CMWs to be used in CBOR-based protocols, web APIs using
JWTs and CWTs, and PKIX artifacts like X.509 certificates.
-->
4) <!--[rfced] We note that Figures 1 and 2 do not have titles while all
other figures and tables in the document do. Please let us know
if/how to update. -->
5) <!--[rfced] We note that Section 7.2.2 of [RFC7515] uses "JWS" when
referring to "flattened JSON Serialization" and "Compact
Serialization". Is an update needed in the sentence below for
consistency?
Original:
A signed-json-cmw uses either the Flattened JSON Serialization
(Section 7.2.2 of [RFC7515]) or the Compact Serialization
(Section 3.1 of [RFC7515]).
Perhaps:
A signed-json-cmw uses either the Flattened JWS JSON Serialization
(Section 7.2.2 of [RFC7515]) or the JWS Compact Serialization
(Section 3.1 of [RFC7515]).
-->
6) <!--[rfced] We had the following questions/comments regarding the use
of the <tt> element in the XML:
a) In Section 4.4.2., we note that "ConceptualMessageWrapper" is
enclosed with the <tt> tag in the section title but not in the first
sentence. Should the instance of "ConceptualMessageWrapper" shown
below be enclosed with "<tt>"?
Original:
Section 6.1.8 of [DICE-ARCH] specifies the ConceptualMessageWrapper (CMW)
format and its corresponding object identifier.
b) We note that the terms in Tables 2 and 4 are enclosed with "<tt>"
but the terms in Tables 3, 5, and 6 are not. Is this okay, or should
any terms in Tables 3, 5, and 6 be tagged?
Table 3: application/cmw+cbor, application/cmw+json, application/cmw+cose,
and application/cmw+jws
Table 5: id-pe-cmw
Table 6: id-mod-cmw-extn
c) Please review the registrations in Sections 9.5.1 - 9.5.4 and let
us know if any terms should be enclosed with "<tt>".
-->
7) <!--[rfced] In the wire representation in Section 5.4, please review
if the U+0484 in the original was intended to be simply (U+0022)?
-->
8) <!-- [rfced] We note that RFC 3647 uses "certification practice
statement" rather than "Certificate Practices Statement". Is an
update needed for consistency?
Current:
Applications that intend to publicly "broadcast" Evidence claims
received from a third party via X.509 Certificates should define a
Certificate Practices Statement [RFC3647] that clearly specifies the
circumstances under which the CA can include such data in the issued
certificate.
-->
9) <!--[rfced] We have included specific questions about the IANA text
below. In addition to responding to those questions, please
review all of the IANA-related updates carefully and let us know
if any further updates are needed.
a) In Table 2, we note that sections within this document are
referenced but no sections are referenced in the "Media Types"
registry <https://www.iana.org/assignments/media-types/>. Should the
IANA registry be updated to match Table 2?
b) Please clarify "Endorsers and Reference-Value providers, Relying
Parties that...". Is "Relying Parties" part of the list of items
(option A)? Or does "Relying Parties" refer to "Attesters, Verifiers,
Endorsers, and Reference-Value providers" (option B)? Note that there
are four instances.
Original:
Attesters, Verifiers, Endorsers and Reference-Value providers, Relying
Parties that need to transfer CMW payloads over HTTP(S), CoAP(S), and
other transports.
Perhaps A:
Attesters, Verifiers, Endorsers, Reference-Value providers, and
Relying Parties that need to transfer CMW payloads over HTTP(S),
CoAP(S), and other transports).
or
Perhaps B:
Attesters, Verifiers, Endorsers, and Reference-Value providers.
These Relying Parties need to transfer CMW payloads over
HTTP(S), CoAP(S), and other transports).
c) We note that the other Claim Descriptions in both the CWT and JWT
registries from Sections 9.1 and 9.2, respectively, use sentence case
(not all words have an initial capital letter. May we update to the
Claim Descriptions in those two sections to match?
d) For Section 9.6.2 (CBOR Tags per RFC 9277), we had a few
questions/concerns:
i) Looking at the end of the Collected CDDL in Section 6 we see:
$cbor-tag /= tag-cm-cbor<1668547091, cbor-collection>
$cbor-tag /= tag-cm-cbor<1668547092, signed-cbor-cmw>
$cbor-tag /= tag-cm-data<1668547093> ; bytes(cmw+json collection)
$cbor-tag /= tag-cm-data<1668547094> ; bytes(cmw+jws)
Which seems to match Figure 7:
$cbor-tag /= tag-cm-cbor<1668547091, cbor-collection>
$cbor-tag /= tag-cm-cbor<1668547092, signed-cbor-cmw>
$cbor-tag /= tag-cm-data<1668547093> ; bytes(cmw+json collection)
$cbor-tag /= tag-cm-data<1668547094> ; bytes(cmw+jws)
However, Table 4 seems to have different descriptions in the "Tag
Content" column than we were expecting based on Section 6 and Figure
7. Please review and let us know if/how these should be made
consistent.
| Tag Number | Tag Content |
| 1668547091 | bytes .cbor cbor-cmw |
| 1668547092 | bytes-wrapped json-cmw |
| 1668547093 | bytes .cbor signed-cbor-cmw |
| 1668547094 | bytes-wrapped signed-json-cmw |
ii) We don't see any corresponding IANA registrations for the
information in Table 4 (nothing was mentioned in the email we received
from IANA regarding this information and we are unable to find these
values in a search of the IANA registries). Should some IANA action
be taken to allocate these numbers (perhaps at
https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml)?
e) Please note that the RPC will communicate any nits/edits to IANA
registry text once AUTH48 completes for consistency.
-->
10) <!-- [rfced] FYI: We updated [X.680] and [X.690] to point to the most
current version of the ITU-T Recommendations.
Original:
[X.680] International Telephone and Telegraph Consultative
Committee, "Abstract Syntax Notation One (ASN.1):
Specification of basic notation", CCITT Recommendation
X.680, July 2002.
[X.690] International Telephone and Telegraph Consultative
Committee, "ASN.1 encoding rules: Specification of basic
encoding Rules (BER), Canonical encoding rules (CER) and
Distinguished encoding rules (DER)", CCITT Recommendation
X.690, July 2002.
Current:
[X.680] ITU-T, "Information technology - Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
<https://www.itu.int/rec/T-REC-X.680>.
[X.690] ITU-T, "Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2021,
February 2021, <https://www.itu.int/rec/T-REC-X.690>.
-->
11) <!--[rfced] We have moved the reference to RFC 8126 to Informative to
match the use most commonly seen in RFCs. Please let us know any
objections. -->
12) <!--[rfced] We updated <artwork> to <sourcecode> in several sections.
Please confirm that this is correct. Also consider whether the
“type" attribute of any sourcecode element should be set and/or
has been set correctly.
The current list of preferred values for "type" is available at
https://www.rfc-editor.org/materials/sourcecode-types.txt. If the
current list does not contain an applicable type, feel free to suggest
additions for consideration. Note that it is also acceptable to leave
the "type" attribute not set.
-->
13) <!--[rfced] We noticed a few titles that seemed a bit different than
the text inside the sections:
a) 3.1.1. CM Type
In the paragraph that follows, we see "cm-type" type.
b) 4.1. Signing CBOR CMW using COSE Sign1
In the paragraph that follows, we see COSE_Sign1.
Please let us know if/how to update.
(See also Section 9.5.3 for "cose-sign1" in the application/cmw+cose
IANA registry if updates may also affect that text.)
-->
14) <!--[rfced] We had the following questions/comments related to terminology
use
throughout the document:
a) Throughout the running text, the following terminology appears to
be used inconsistently. Please review these occurrences and let us
know if/how they may be made consistent.
CBOR Tag vs. CBOR tag
Collection (11) vs. collection (1)
[Note: Is this one lowercase instance ok, or does it need an update?
"It provides a namespace in which the collection labels are interpreted".
Content-Format vs. content format
Content-Type vs. content type
[Note: Are the two instances of "content type" correct in Sections 4.1 and
4.2?]
X.509 Certificates (6) vs. X.509 certificates (1)
[Note: RFC 9334 uses the lowercase form.]
b) FYI: We updated "Conceptual Message" to "conceptual message" per
feedback from the intake form.
c) In addition to "Collection CMW", we also see instances of "CMW
collection". Please review and let us know if/how to update for
uniformity.
-->
15) <!--[rfced] We had the following questions/comments related to
abbreviation use throughout the document:
a) FYI - We have added expansions for abbreviations on first use per
Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review these and
each expansion in the document carefully to ensure correctness.
b) As recommended in the Web Portion of the Style Guide
<https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>, once an
abbreviation is introduced, the abbreviated form should be used
thereafter. Please consider if you would like to apply this style for
the following terms:
Relying Party (RP)
JSON Web Token (JWT)
remote attestation procedures (not always with the abbreviation)
Certificate Signing Request (CSR)
Certificate Revocation List (CRL)
c) We see REST expanded near the end of Section 1. However, we note
the REST is used in Figures 1 and 2. Might it be helpful to the
reader to add an expansion somewhere nearer the first use?
d) This document uses JOSE only in the title of Section 4.3: is there
another place an expansion could be placed?
-->
16) <!--[rfced] Please review the "Inclusive Language" portion of the
online Style Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this
nature typically result in more precise language, which is
helpful for readers.
Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice.
-->
Thank you.
Karen Moore and Megan Ferguson
RFC Production Center
*****IMPORTANT*****
RFC Author(s):
--------------
Final Review for RFC-to-be 9999 <draft-ietf-rats-msg-wrap>
Your document is now available for Final Review (previously AUTH48). Once it
has been
reviewed and approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies;
see the Unavailable Authors section
(https://authors.ietf.org/rfc-publication-process#unavailable-authors).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using 'REPLY ALL' as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* [email protected] (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* [email protected], which is an archival mailing list
to preserve discussion about the document while in the RPC editorial
queue; it is not an active discussion list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
[email protected] will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use 'REPLY ALL',
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9999.xml
https://www.rfc-editor.org/authors/rfc9999.html
https://www.rfc-editor.org/authors/rfc9999.pdf
https://www.rfc-editor.org/authors/rfc9999.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9999-diff.html
https://www.rfc-editor.org/authors/rfc9999-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9999-xmldiff1.html
Tracking progress
-----------------
Details on the status of your Final Review are here:
https://queue.rfc-editor.org/final-review/rfc9999/
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC 9999 (draft-ietf-rats-msg-wrap)
Title : RATS Conceptual Messages Wrapper (CMW)
Author(s) : H. Birkholz,
N. Smith,
T. Fossati,
H. Tschofenig,
D. Glaze
WG Chair(s) : Ned Smith, Kathleen Moriarty
Area Director(s) : Deb Cooley, Christopher Inacio
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
