Hi Thomas, Thank you for your reply! We have updated our files accordingly. We have a few additional questions:
1) We note that “Collection CMW” is preferred. Please let us know if/how you would like this sentence to be updated. Current: CMW Records, Tags, and Collections alone do not offer authenticity, integrity protection, or confidentiality. Perhaps: Record, Tag, and Collection CMWs alone do not offer authenticity, integrity protection, or confidentiality. 2) In Section 5.4, we replaced "҄@\xA0D\xD9\u0001\xF5\xA0\@" with "…". Please review and let us know if any further changes are needed. 3) We moved Dionna Glaze to the Acknowledgements section. If she should be listed as a contributor instead, please let us know. —Files— Note that it may be necessary for you to refresh your browser to view the most recent version. Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC. Please contact us with any further updates or with your approval of the document in its current form. We will await approvals from each author prior to moving forward in the publication process. Updated XML file: https://www.rfc-editor.org/authors/rfc9999.xml Updated output files: https://www.rfc-editor.org/authors/rfc9999.txt https://www.rfc-editor.org/authors/rfc9999.pdf https://www.rfc-editor.org/authors/rfc9999.html Diff files showing all changes made during Final Review (formally AUTH48): https://www.rfc-editor.org/authors/rfc9999-auth48diff.html https://www.rfc-editor.org/authors/rfc9999-auth48rfcdiff.html (side by side) Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9999-diff.html https://www.rfc-editor.org/authors/rfc9999-rfcdiff.html (side by side) For the status of this document, please see: https://www.rfc-editor.org/auth48/rfc9999 Best regards, Karen Moore RFC Production Center > On Jun 5, 2026, at 7:00 AM, Thomas Fossati via auth48archive > <[email protected]> wrote: > > Hi Karen and Megan, > > Thank you very much for your work. We are forever grateful to you for > bestowing this splendid RFC number upon us :-) > > See our replies inline. > > cheers! > > On Tue, 2 Jun 2026 at 00:16, <[email protected]> wrote: >> >> 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) >> --> > > ACK > >> 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. --> > > Sadly, Dionna said that she wants to be moved to the Acknowledgements > section. > >> 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. >> >> --> > > It should say: > > "Together, these mechanisms allow CMWs to be used in [...]" > >> 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. --> > > Could you please add the following: > > Figure 1: "Conveyance of RATS Conceptual Messages in the > 'background-check' topology" > > Figure 2: "Conveyance RATS Conceptual Messages in the 'passport' > topology" > > thank you! > >> 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]). >> --> > > The original is fine as-is. > >> 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. > > We think it would be better to remove the <tt> from the title and leave > the body text as it is. > >> 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 > > It would probably be better to remove the <tt> from tables 2 and 4. > >> 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>". >> --> > > These are fine as they are. > >> 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)? >> --> > > The annotations are automatically generated by Carsten's cbor2pretty.rb > tool. In this case, we don't think there's any reason to attempt a > string conversion, as the encoded message is just a series of random > bytes. If this is a problem, we suggest replacing the string in the > comment with an ellipsis, as no information would really be lost. > >> 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. >> --> > > Yes, we should use "certification practice statement" instead. > >> 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? > > Yes, as long as it doesn't cause too much disruption for IANA. > Otherwise, we can stick to their established practices. > >> 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). > > (A) is the right interpretation. > > >> 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? > > We should change both §§9.1 and 9.2 to: > > "Claims Description: RATS Conceptual Message Wrapper" > > (i.e., without the 'A', but keeping the capitalisation as-is) > >> >> 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 | > > Thanks very much for spotting this bug! > > We (I) managed to confuse myself with the numbers :-( > The CDDL is authoritative, and Table 4 should just reflect that: > > Tag Number | Tag Content > -----------+------------------------------ > 1668547091 | bytes .cbor cbor-cmw > 1668547092 | bytes .cbor signed-cbor-cmw > 1668547093 | bytes-wrapped json-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)? > > Yes, that's because no explicit registrations are required. > RFC9277 allocates a range in the CBOR tag space for registered > CoAP content formats. Once the registrations in Table 3 have > been made, four new CBOR tags were automatically obtained from > the RFC9277 range. > >> e) Please note that the RPC will communicate any nits/edits to IANA >> registry text once AUTH48 completes for consistency. >> --> > > ACK > >> 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>. >> --> > > Current looks much better. > >> 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. --> > > No objection. > (While understanding the rules is important, there are other safeguards > in place, so this could also be treated as an informative reference.) > >> 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. >> --> > > All looks good, except in §5.7 "Use in JWT", where the type should be > "json" rather than unspecified. > >> 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. > > The title should be changed to the fully expanded "Conceptual Message > Type" instead of "CM 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. > > The title could be updated to use COSE_Sign1 instead. > >> (See also Section 9.5.3 for "cose-sign1" in the application/cmw+cose >> IANA registry if updates may also affect that text.) >> >> --> > > No, that one is not impacted. > >> 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 > > Unless when used in titles, it should be "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". > > We think it should be capitalised when used in combination with CMW > (i.e., "Collection CMW") and lowercase when used on its own > ("collection"). > >> Content-Format vs. content format > > We should use Content-Format when paired with ID ("Content-Format ID") > and RFC9193's "content format" otherwise. > >> Content-Type vs. content type >> [Note: Are the two instances of "content type" correct in Sections 4.1 >> and 4.2?] > > No, they should be "media type" instead. Thanks for catching another > bug! > >> X.509 Certificates (6) vs. X.509 certificates (1) >> [Note: RFC 9334 uses the lowercase form.] > > We should use lowercase "certificate"/"certificates". > >> b) FYI: We updated "Conceptual Message" to "conceptual message" per >> feedback from the intake form. > > ACK > >> 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. >> --> > > "CMW collection" should be "Collection CMW" instead. > >> 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) > > OK > >> 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? > > This doesn't seem necessary. > In fact, it was quite surprising to see that the REST entry at > https://rpc-wiki.rfc-editor.org/doku.php?id=abbrev_list doesn't have an > asterisk :-) > >> d) This document uses JOSE only in the title of Section 4.3: is there >> another place an expansion could be placed? >> --> > > There is a bug in the current title: "Transporting CMW in COSE and JOSE > Web Tokens" should be "Transporting CMW in COSE and JSON Web Tokens" > instead. > > Then we wouldn't need to expand JOSE :-) > >> 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. >> --> > > We couldn't find anything sticking out. > >> Thank you. >> >> Karen Moore and Megan Ferguson >> RFC Production Center > > Thank you both for the great work. > > cheers! > > -- > auth48archive mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
