There is a stray $EAT-CBOR-Tagged-Token in Section 3. It should be $CBOR-Tagged-Token (as appears in section 7.3.2). Sorry for not catching this sooner.
On 2/7/25, 5:22 PM, "Karen Moore" <kmo...@staff.rfc-editor.org <mailto:kmo...@staff.rfc-editor.org>> wrote: Dear Giri and *Roman (AD), Thank you for providing the document that outlines Round 4 of the suggested changes. We have updated our files accordingly. Please review, especially the formatting/spacing in Section 4.2.3.3, and let us know if any further changes are desired or if you approve the document in its current form (the new formatting/spacing is best viewed in this file: https://www.rfc-editor.org/authors/rfc9711.txt <https://www.rfc-editor.org/authors/rfc9711.txt>). *Roman, please review the updates that were made to Sections 3, 4.1, 4.2.3.2, 4.2.3.3, 4.2.10, 4.2.18, 5, 7.3, 7.3.1, 7.3.2, and 9.1 and Appendices A.1.7, A.2.2, A.2.3, B.2, and D during AUTH48, and let us know if you approve. Please review the changes in this file: https://www.rfc-editor.org/authors/rfc9711-auth48diff.html <https://www.rfc-editor.org/authors/rfc9711-auth48diff.html>. Note that the authors provided comments for some of the changes in the attached word document, if needed. —Files (please refresh)— The updated XML file is here: https://www.rfc-editor.org/authors/rfc9711.xml <https://www.rfc-editor.org/authors/rfc9711.xml> The updated output files are here: https://www.rfc-editor.org/authors/rfc9711.txt <https://www.rfc-editor.org/authors/rfc9711.txt> https://www.rfc-editor.org/authors/rfc9711.pdf <https://www.rfc-editor.org/authors/rfc9711.pdf> https://www.rfc-editor.org/authors/rfc9711.html <https://www.rfc-editor.org/authors/rfc9711.html> These diff files show all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9711-auth48diff.html <https://www.rfc-editor.org/authors/rfc9711-auth48diff.html> https://www.rfc-editor.org/authors/rfc9711-auth48rfcdiff.html <https://www.rfc-editor.org/authors/rfc9711-auth48rfcdiff.html> (side by side) These diff files show only the change made during the last editing round: https://www.rfc-editor.org/authors/rfc9711-lastdiff.html <https://www.rfc-editor.org/authors/rfc9711-lastdiff.html> https://www.rfc-editor.org/authors/rfc9711-lastrfcdiff.html <https://www.rfc-editor.org/authors/rfc9711-lastrfcdiff.html> (side by side) These diff files show all changes made to date: https://www.rfc-editor.org/authors/rfc9711-diff.html <https://www.rfc-editor.org/authors/rfc9711-diff.html> https://www.rfc-editor.org/authors/rfc9711-rfcdiff.html <https://www.rfc-editor.org/authors/rfc9711-rfcdiff.html> (side by side) Best regards, RFC Editor/kc > On Feb 7, 2025, at 7:37 AM, Giridhar Mandyam <giridhar.mand...@gmail.com > <mailto:giridhar.mand...@gmail.com>> wrote: > > Dear RFC Ed, > Enclosed are the editors' latest responses. We think we are ready to publish > after the enclosed changes are made. Thanks for all of your patience, and > your efforts in getting this document together. > > -Giri > > On Wed, Feb 5, 2025 at 2:08 PM Karen Moore <kmo...@staff.rfc-editor.org > <mailto:kmo...@staff.rfc-editor.org>> wrote: > Dear Giri, > > Thank you for providing the document that outlines Round 3 of the authors’ > suggested changes. These updates are now reflected in our files. Please > review carefully (especially changes to the JSON examples), and let us know > if any further changes are needed. We have some additional questions. > > 1) We have not heard back from you yet regarding the following. Please > confirm if we may remove the quote marks from the terms listed in the JWT > Claim Name fields in Section 10.2 per IANA’s preference. If you have any > questions for IANA about this change, please let us know (as we have now > removed IANA from this thread). > > > 1) Based on discussion with IANA, they prefer that the document match the > > "CBOR Web Token (CWT) Claims" registry (i.e., no quotation marks in the JWT > > Claim Name fields in Section 10.2; see the registry at > > <https://www.iana.org/assignments/cwt> > > <https://www.iana.org/assignments/cwt>>). We are CCing IANA on this > > thread in case you have questions. If none, we will update Section 10.2 per > > their preference. > > > >> b) Section 10.2. May we remove all quote marks from the JWT Claim Name > >> fields? We note that quote marks are not used in the "CBOR Web Token > >> (CWT) Claims" registry <https://www.iana.org/assignments/cwt> > >> <https://www.iana.org/assignments/cwt>>. > >> For example: > >> OLD: JWT Claim Name: "eat_nonce" > >> NEW: JWT Claim Name: eat_nonce > >> > >> EDITORS’ RESPONSE: Original text should not be changed. Please revert. > > 2) Regarding the pointer to the EAT WG GitHub repository, we changed the link > to a citation per guidance in our online style guide (see "Referencing > Web-Based Public Code Repositories (e.g., GitHub)” at > <https://www.rfc-editor.org/styleguide/part2/> > <https://www.rfc-editor.org/styleguide/part2/>>). Please let us know if > any additional updates are needed. > > Original: > See https://github.com/ietf-rats-wg/eat <https://github.com/ietf-rats-wg/eat> > for additional information and stub files, when > using the CDDL presented in this section to validate EAT protocol > messages. > > Current: > See [EAT-GitHub] for additional information and stub files, when > using the CDDL presented in this section to validate EAT protocol > messages. > > Informative References Entry: > [EAT-GitHub] > "Entity Attestation Token IETF Draft Standard", > commit 62c726b, January 2024, > <https://github.com/ietf-rats-wg/eat> > <https://github.com/ietf-rats-wg/eat>>. > > —Files (please refresh)— > > The updated XML file is here: > https://www.rfc-editor.org/authors/rfc9711.xml > <https://www.rfc-editor.org/authors/rfc9711.xml> > > The updated output files are here: > https://www.rfc-editor.org/authors/rfc9711.txt > <https://www.rfc-editor.org/authors/rfc9711.txt> > https://www.rfc-editor.org/authors/rfc9711.pdf > <https://www.rfc-editor.org/authors/rfc9711.pdf> > https://www.rfc-editor.org/authors/rfc9711.html > <https://www.rfc-editor.org/authors/rfc9711.html> > > These diff files show all changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9711-auth48diff.html > <https://www.rfc-editor.org/authors/rfc9711-auth48diff.html> > https://www.rfc-editor.org/authors/rfc9711-auth48rfcdiff.html > <https://www.rfc-editor.org/authors/rfc9711-auth48rfcdiff.html> (side by side) > > This diff file shows all changes made to date: > https://www.rfc-editor.org/authors/rfc9711-diff.html > <https://www.rfc-editor.org/authors/rfc9711-diff.html> > > Best regards, > RFC Editor/kc > > > On Jan 28, 2025, at 11:44 AM, Karen Moore <kmo...@staff.rfc-editor.org > > <mailto:kmo...@staff.rfc-editor.org>> wrote: > > > > Dear Giri, > > > > We have updated our files with the proposed changes provided on January > > 25th. Please review the updates (especially changes to the sourcecode to > > ensure we captured all edits correctly) and let us know if any further > > changes are needed. Note that we have an additional clarification below. > > > > 1) Based on discussion with IANA, they prefer that the document match the > > "CBOR Web Token (CWT) Claims" registry (i.e., no quotation marks in the JWT > > Claim Name fields in Section 10.2; see the registry at > > <https://www.iana.org/assignments/cwt> > > <https://www.iana.org/assignments/cwt>>). We are CCing IANA on this > > thread in case you have questions. If none, we will update Section 10.2 per > > their preference. > > > >> b) Section 10.2. May we remove all quote marks from the JWT Claim Name > >> fields? We note that quote marks are not used in the "CBOR Web Token > >> (CWT) Claims" registry <https://www.iana.org/assignments/cwt> > >> <https://www.iana.org/assignments/cwt>>. > >> For example: > >> OLD: JWT Claim Name: "eat_nonce" > >> NEW: JWT Claim Name: eat_nonce > >> > >> EDITORS’ RESPONSE: Original text should not be changed. Please revert. > > > > > > > > —Files (please refresh)— > > > > The updated XML file is here: > > https://www.rfc-editor.org/authors/rfc9711.xml > > <https://www.rfc-editor.org/authors/rfc9711.xml> > > > > The updated output files are here: > > https://www.rfc-editor.org/authors/rfc9711.txt > > <https://www.rfc-editor.org/authors/rfc9711.txt> > > https://www.rfc-editor.org/authors/rfc9711.pdf > > <https://www.rfc-editor.org/authors/rfc9711.pdf> > > https://www.rfc-editor.org/authors/rfc9711.html > > <https://www.rfc-editor.org/authors/rfc9711.html> > > > > These diff files show only the changes made during the last edit round: > > https://www.rfc-editor.org/authors/rfc9711-lastdiff.html > > <https://www.rfc-editor.org/authors/rfc9711-lastdiff.html> > > https://www.rfc-editor.org/authors/rfc9711-lastrfcdiff.html > > <https://www.rfc-editor.org/authors/rfc9711-lastrfcdiff.html> (side by side) > > > > These diff files show all changes made during AUTH48: > > https://www.rfc-editor.org/authors/rfc9711-auth48diff.html > > <https://www.rfc-editor.org/authors/rfc9711-auth48diff.html> > > https://www.rfc-editor.org/authors/rfc9711-auth48rfcdiff.html > > <https://www.rfc-editor.org/authors/rfc9711-auth48rfcdiff.html> (side by > > side) > > > > This diff file shows all changes made to date: > > https://www.rfc-editor.org/authors/rfc9711-diff.html > > <https://www.rfc-editor.org/authors/rfc9711-diff.html> > > > > For the AUTH48 status of this document, please see: > > https://www.rfc-editor.org/auth48/rfc9711 > > <https://www.rfc-editor.org/auth48/rfc9711> > > > > Best regards, > > RFC Editor/kc > > > > > >> From: Karen Moore <kmo...@staff.rfc-editor.org > >> <mailto:kmo...@staff.rfc-editor.org>> > >> Subject: Re: [auth48] AUTH48: RFC-to-be 9711 <draft-ietf-rats-eat-31> for > >> your review > >> Date: January 27, 2025 at 2:54:40 PM PST > >> To: "lgl securitytheory.com" <l...@securitytheory.com > >> <mailto:l...@securitytheory.com>>, Giridhar Mandyam > >> <giridhar.mand...@gmail.com <mailto:giridhar.mand...@gmail.com>>, Carl > >> Wallace <c...@redhoundsoftware.com <mailto:c...@redhoundsoftware.com>>, > >> Jeremy O'Donoghue <jodon...@qti.qualcomm.com > >> <mailto:jodon...@qti.qualcomm.com>> > >> Cc: RFC Editor <rfc-edi...@rfc-editor.org > >> <mailto:rfc-edi...@rfc-editor.org>>, "rats-...@ietf.org > >> <mailto:rats-...@ietf.org>" <rats-...@ietf.org > >> <mailto:rats-...@ietf.org>>, rats-chairs <rats-cha...@ietf.org > >> <mailto:rats-cha...@ietf.org>>, "Smith, Ned" <ned.sm...@intel.com > >> <mailto:ned.sm...@intel.com>>, Roman Danyliw <r...@cert.org > >> <mailto:r...@cert.org>>, auth48archive <auth48archive@rfc-editor.org > >> <mailto:auth48archive@rfc-editor.org>> > >> > >> Dear Giri and *Laurence, > >> > >> Thank you for providing the document that outlines further suggested > >> changes; we are working on the updates and will get back to you shortly. > >> > >> *Laurence, we have updated our files to reflect changes based on the > >> responses provided by Giri on January 22nd. We have not incorporated the > >> changes yet that Giri sent on January 25th. While we are working on > >> incorporating those updates, please visit our mail archive to catch up on > >> any email correspondence you may have missed at > >> <https://mailarchive.ietf.org/arch/search/?q=rfc9711>. You > >> <https://mailarchive.ietf.org/arch/search/?q=rfc9711>. You> > >> can also view the changes that have been made to date by accessing the > >> files below. Should you have any questions, please let us know. > >> > >> —Files (please refresh)— > >> > >> The updated XML file is here: > >> https://www.rfc-editor.org/authors/rfc9711.xml > >> <https://www.rfc-editor.org/authors/rfc9711.xml> > >> > >> The updated output files are here: > >> https://www.rfc-editor.org/authors/rfc9711.txt > >> <https://www.rfc-editor.org/authors/rfc9711.txt> > >> https://www.rfc-editor.org/authors/rfc9711.pdf > >> <https://www.rfc-editor.org/authors/rfc9711.pdf> > >> https://www.rfc-editor.org/authors/rfc9711.html > >> <https://www.rfc-editor.org/authors/rfc9711.html> > >> > >> These diff files show all changes made during AUTH48: > >> https://www.rfc-editor.org/authors/rfc9711-auth48diff.html > >> <https://www.rfc-editor.org/authors/rfc9711-auth48diff.html> > >> https://www.rfc-editor.org/authors/rfc9711-auth48rfcdiff.html > >> <https://www.rfc-editor.org/authors/rfc9711-auth48rfcdiff.html> (side by > >> side) > >> > >> This diff file shows all changes made to date: > >> https://www.rfc-editor.org/authors/rfc9711-diff.html > >> <https://www.rfc-editor.org/authors/rfc9711-diff.html> > >> > >> Best regards, > >> RFC Editor/kc > >> > >> > >> On Jan 27, 2025, at 9:55 AM, lgl securitytheory.com > >> <l...@securitytheory.com <mailto:l...@securitytheory.com>> wrote: > >> > >> Hi, > >> > >> I’m a little confused about the status here. Has the RFC Editor processed > >> everything so that all proposed changes appear in the AUTH48 diff? > >> > >> I am waiting for that to happen before I do a review of those changes. > >> > >> Also, I’m not sure the Jan 22 email from Karen Moore was sent to me. I > >> can’t find it in my inbox. > >> > >> LL > >> > >> > >> On Jan 25, 2025, at 10:50 AM, Giridhar Mandyam <giridhar.mand...@gmail.com > >> <mailto:giridhar.mand...@gmail.com>> wrote: > >> > >> Thanks for the quick response. Enclosed please find the editors' response. > >> Note that in the process of re-validation of CDDL and cbor.diag examples > >> based on the last round of revisions, we encountered some changes that > >> need to be made in the document. Sorry about this, but the CDDL validator > >> that is in widespread use in the IETF has been evolving. > >> > >> -Giri > >> > >> On Wed, Jan 22, 2025 at 4:43 PM Karen Moore <kmo...@staff.rfc-editor.org > >> <mailto:kmo...@staff.rfc-editor.org>> wrote: > >> Dear Giri, > >> > >> Thank you for your review and detailed reply. We have updated our files > >> based on your responses. Please see some additional > >> questions/clarifications below. > >> > >> 1) In Section 10.5, we updated “Integer" to “Value”; however, there is > >> still a mismatch with this document and the columns in the IANA registry. > >> In the "Entity Attestation Token (EAT) Intended Uses” registry > >> (https://www.iana.org/assignments/rats/rats.xhtml > >> <https://www.iana.org/assignments/rats/rats.xhtml>), the columns are > >> “Value”, Description”, and “Reference”, but this document lists “Value”, > >> “Name”, and “Description”. Should this document be updated as follows to > >> match the registry? > >> > >> Current: > >> The three columns for the registry are: > >> > >> 1. Value: This is a unique integer that is used to identify the > >> intended use in CBOR-encoded tokens. > >> > >> 2. Name: This is unique short descriptive string that is used to > >> identify the use in JSON-encoded tokens. > >> > >> 3. Description: This is one or more text paragraphs that > >> sufficiently define what the intended use means. It may also be > >> a reference to another document. > >> > >> Perhaps: > >> 1. Value: This is a unique integer that is used to identify the > >> intended use in CBOR-encoded tokens. > >> > >> 2. Description: This is one or more text paragraphs that > >> sufficiently define what the intended use means. It may also be > >> a reference to another document. > >> > >> 3. Reference: This field contains a reference to the defining > >> specification. > >> > >> #27 g) Section 10.5. The columns for the "Entity Attestation Token > >> (EAT) Intended Uses" registry are "Integer", "Name", and > >> "Description" in this document, but "Value", "Description", and > >> "Reference" in the IANA registry <https://www.iana.org/assignments/rats> > >> <https://www.iana.org/assignments/rats>>. > >> Which one is correct? If the IANA registry is correct, please provide > >> updated text for Section 10.5 where it describes the three columns. > >> > >> > >> [EDITORS’ RESPONSE]: Please make change as below to synchronize the EAT > >> text with the IANA registry: > >> > >> ORIGINAL: > >> Integer: This is a unique integer used to identify the intended use in > >> CBOR-encoded tokens. > >> > >> NEW: > >> Value: This is a unique integer used to identify the intended use in > >> CBOR-encoded tokens. > >> > >> > >> 2) Please note that we made the following change (“use cases” instead of > >> “use case”). Please let us know if this update is acceptable. > >> > >> Original: > >> However, EAT is intended for use in low-security use cases > >> the same as high-security use case. > >> > >> Current: > >> However, EAT is intended for use in low-security use cases > >> the same as high-security use cases. > >> > >> 3) Per your explanation, we left “detached EAT bundle” as lowercase, and > >> we made one capitalized instance lowercase for consistency (see Section > >> 4.2.18). If this is incorrect, please let us know. > >> > >> —Files— > >> > >> The updated XML file is here: > >> https://www.rfc-editor.org/authors/rfc9711.xml > >> <https://www.rfc-editor.org/authors/rfc9711.xml> > >> > >> The updated output files are here: > >> https://www.rfc-editor.org/authors/rfc9711.txt > >> <https://www.rfc-editor.org/authors/rfc9711.txt> > >> https://www.rfc-editor.org/authors/rfc9711.pdf > >> <https://www.rfc-editor.org/authors/rfc9711.pdf> > >> https://www.rfc-editor.org/authors/rfc9711.html > >> <https://www.rfc-editor.org/authors/rfc9711.html> > >> > >> These diff files show all changes made during AUTH48: > >> https://www.rfc-editor.org/authors/rfc9711-auth48diff.html > >> <https://www.rfc-editor.org/authors/rfc9711-auth48diff.html> > >> https://www.rfc-editor.org/authors/rfc9711-auth48rfcdiff.html > >> <https://www.rfc-editor.org/authors/rfc9711-auth48rfcdiff.html> (side by > >> side) > >> > >> This diff file shows all changes made to date: > >> https://www.rfc-editor.org/authors/rfc9711-diff.html > >> <https://www.rfc-editor.org/authors/rfc9711-diff.html> > >> > >> 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. > >> > >> For the AUTH48 status of this document, please see: > >> https://www.rfc-editor.org/auth48/rfc9711 > >> <https://www.rfc-editor.org/auth48/rfc9711> > >> > >> Thank you, > >> RFC Editor/kc > >> > >> > >> On Jan 22, 2025, at 7:54 AM, Giridhar Mandyam via auth48archive > >> <auth48archive@rfc-editor.org <mailto:auth48archive@rfc-editor.org>> wrote: > >> > >> Please see enclosed. These are the consolidated editors' responses. > >> > >> -Giri Mandyam > >> > >> > >> > >> On Jan 13, 2025, at 8:49 PM, RFC Editor via auth48archive > >> <auth48archive@rfc-editor.org <mailto:auth48archive@rfc-editor.org>> wrote: > >> > >> Authors, > >> > >> While reviewing this document during AUTH48, please resolve (as necessary) > >> the following questions, which are also in the XML file. > >> > >> 1) <!--[rfced] Section 1. FYI - We expanded the first mentions of "ueid" > >> and "oemid" as shown below. Please let us know if this is not accurate. > >> > >> Original: > >> The ueid is > >> effectively a serial number uniquely identifying the device. This > >> ueid is the base64url encoding of a 48-bit MAC address preceded by > >> the type byte 0x02. The oemid identifies the manufacturer using a > >> Private Enterprise Number [PEN]. > >> > >> Current: > >> The ueid (Universal Entity ID) is > >> effectively a serial number uniquely identifying the device. This > >> ueid is the base64url encoding of a 48-bit Media Access Control (MAC) > >> address preceded by the type byte 0x02. The oemid (Hardware OEM ID) > >> identifies the manufacturer using a Private Enterprise Number (PEN) [PEN]. > >> --> > >> > >> > >> 2) <!--[rfced] Section 1.2. Please clarify the latter part of this > >> sentence. Is the intended meaning that EAT is not used for > >> specific token definition as shown below? > >> > >> Original: > >> EAT is a framework for defining attestation tokens for specific use > >> cases, not a specific token definition. > >> > >> Perhaps: > >> EAT is a framework that is used for defining attestation tokens for > >> specific use cases; it is not used for specific token definition. > >> --> > >> > >> > >> 3) <!--[rfced] Sections 1.2 and 4.2.18. The term "follow-on documents" > >> hasn't been used since early RFCs. Would it be clearer to say > >> "subsequent documents" as shown below? Note that there are 2 instances. > >> > >> Original: > >> Finally, the notion of an EAT profile is introduced that facilitates > >> the creation of narrowed definitions of EATs for specific use cases in > >> follow-on documents. > >> [...] > >> > >> Nested tokens can be one of three types as defined in this document or > >> types standardized in follow-on documents (e.g., [UCCS]). > >> > >> Perhaps: > >> Finally, this document introduces the notion of an EAT profile that > >> facilitates the creation of narrowed definitions of EATs for > >> specific use cases in subsequent documents. > >> [...] > >> > >> Nested tokens can be one of three types as defined in this document or > >> types that are standardized in subsequent documents (e.g., [UCCS]). > >> --> > >> > >> > >> 4) <!--[rfced] Section 2. We note that RFC 7515 (Section 2) defines > >> "base64url encoding" rather than "base64url encoded". Would you > >> like to update the terminology list to match RFC 7515, or is this > >> variance okay? > >> > >> Original: > >> base64url-encoded: base64url-encoded is as described in [RFC7515], > >> i.e., using URL- and filename-safe character set [RFC4648] with > >> all trailing '=' characters omitted and without the inclusion of > >> any line breaks, whitespace, or other additional characters. > >> > >> Perhaps: > >> base64url encoding: As defined in [RFC7515], base64 encoding > >> uses a URL- and filename-safe character set [RFC4648] with > >> all trailing '=' characters omitted and without the > >> inclusion of any line breaks, whitespace, or other additional > >> characters. > >> --> > >> > >> > >> 5) <!--[rfced] Section 2. We added a citation to RFC 9052 for "COSE" for > >> easy > >> reference. If that is not correct or desired, please let us know. > >> > >> Original: > >> Claim Key: The CBOR map key used to identify a claim. (The term > >> "Claim Key" comes from CWT. This document, like COSE, uses the > >> term "label" to refer to CBOR map keys to avoid confusion with > >> cryptographic keys.) > >> > >> Current: > >> Claim Key: The CBOR map key used to identify a claim. (The term > >> "Claim Key" comes from CWT. This document, like COSE [RFC9052], > >> uses the term "label" to refer to CBOR map keys to avoid > >> confusion with cryptographic keys.) > >> --> > >> > >> > >> 6) <!--[rfced] Section 4. Can "of most of what is defined" be rephrased > >> for clarity as shown below? > >> > >> Original: > >> This specification includes a CDDL definition of most of what is > >> defined in [RFC8392]. Similarly, this specification includes CDDL > >> for most of what is defined in [RFC7519]. > >> > >> Perhaps: > >> This specification includes a CDDL definition that is based on the > >> CDDL definitions in [RFC8392] and [RFC7519]. > >> --> > >> > >> > >> 7) <!--[rfced] Section Titles > >> > >> a) Should the title of Section 4.2.2 be updated as shown > >> below (i.e., remove "(SUEIDs)") for consistency with the > >> other section titles? (See the separate question re: removing > >> the hyphen in 'semipermanent'.) > >> > >> Original: > >> 4.2.1. ueid (Universal Entity ID) Claim > >> 4.2.2. sueids (Semi-permanent UEIDs) Claim (SUEIDs) > >> > >> Perhaps: > >> 4.2.1. ueid (Universal Entity ID) Claim > >> 4.2.2. sueids (Semipermanent UEIDs) Claim > >> > >> ... > >> b) Should the title of Section 4.2.18 contain "Claim" for > >> consistency? > >> > >> Original: > >> 4.2.16. measurements (Measurements) Claim > >> 4.2.17. measres (Software Measurement Results) Claim > >> 4.2.18 submods (Submodules) > >> > >> Perhaps: > >> 4.2.16. measurements (Measurements) Claim > >> 4.2.17. measres (Software Measurement Results) Claim > >> 4.2.18 submods (Submodules) Claim > >> --> > >> > >> > >> 8) <!--[rfced] Section 4.2.3.2. Please clarify what "these" refers to in > >> "Many companies already have purchased one of these" (last sentence). > >> > >> Original: > >> The IEEE operates a global registry for MAC addresses and company > >> IDs. This claim uses that database to identify OEMs. The contents > >> of the claim may be either an IEEE MA-L, MA-M, MA-S, or CID > >> [IEEE-RA]. An MA-L, formerly known as an OUI, is a 24-bit value used > >> as the first half of a MAC address. Similarly, MA-M is a 28-bit > >> value used as the first part of a MAC address, and MA-S, formerly > >> known as OUI-36, is a 36-bit value. Many companies already have > >> purchased one of these. > >> --> > >> > >> > >> 9) <!--[rfced] Section 4.2.3.3. This sentence cites the application > >> for PENs (https://pen.iana.org/pen/PenApplication.page > >> <https://pen.iana.org/pen/PenApplication.page>), so it seems > >> either the text or the reference should be updated. Which do you prefer? > >> > >> Original: > >> IANA maintains a registry for Private Enterprise Numbers [PEN]. > >> > >> where > >> [PEN] "Private Enterprise Number (PEN) Request", n.d., > >> <https://pen.iana.org/pen/PenApplication.page> > >> <https://pen.iana.org/pen/PenApplication.page>>. > >> > >> > >> Option A (if the reference remains the same): > >> IANA maintains the application for Private Enterprise > >> Numbers [PEN]. > >> > >> Option B (if the reference is changed to the registry itself): > >> > >> IANA maintains a registry for Private Enterprise Numbers [PEN]. > >> > >> where: > >> [PEN] IANA, "Private Enterprise Numbers (PENs)", > >> <https://www.iana.org/assignments/enterprise-numbers/> > >> <https://www.iana.org/assignments/enterprise-numbers/>>. > >> --> > >> > >> > >> 10) <!--[rfced] Section 4.2.7. A word is missing after "may be". Please > >> confirm if "used" is the correct word as shown below. > >> > >> Original: > >> The "manifests" claim Section 4.2.15 may be instead if this is too > >> simple. > >> > >> Current: > >> The "manifests" claim (Section 4.2.15) may be used instead if this > >> is too simple. > >> --> > >> > >> > >> 11) <!-- [rfced] Section 4.2.10. We notice that [W3C.GeoLoc] is listed as > >> an informative reference, whereas [WGS84] is a normative > >> reference. Considering the key word "MUST" in this sentence, > >> should [W3C.GeoLoc] be listed as a normative reference? > >> > >> Original: > >> Latitude, longitude, altitude, accuracy, altitude-accuracy, > >> heading and speed MUST be as defined in the W3C Geolocation > >> API [W3C.GeoLoc] (which, in turn, is based on [WGS84]). > >> --> > >> > >> > >> 12) <!--[rfced] Section 4.2.10. With the expansion of "GNSS", > >> should this be rephrased? > >> > >> Original: > >> For example, it might have been minutes or hours or more > >> since the last contact with a GNSS satellite. > >> > >> Current: > >> For example, it might have been minutes, hours, or more > >> since the last contact with a Global Navigation Satellite > >> System (GNSS) satellite. > >> > >> Perhaps: > >> For example, it might have been minutes, hours, or more > >> since the last contact with a satellite in the Global > >> Navigation Satellite System (GNSS). > >> --> > >> > >> > >> 13) <!--[rfced] Section 4.2.15. Should the word 'tag' be added here, > >> as the term 'SWID tag' is used in RFC 9393? > >> > >> Original: > >> For example, the manifest may be a CBOR-encoded CoSWID, an > >> XML-encoded SWID or other. > >> > >> Current: > >> For example, the manifest may be a CBOR-encoded CoSWID, an > >> XML-encoded Software Identification (SWID), or other. > >> > >> Perhaps: > >> For example, the manifest may be a CBOR-encoded CoSWID, an > >> XML-encoded Software Identification (SWID) tag, or other. > >> --> > >> > >> > >> 14) <!--[rfced] Sections 4.2.15 and 4.2.16. RFC 7252 uses Content-Format > >> "identifier" rather than "integer". Given this, should "integer" > >> be removed or replaced with "identifier" as shown below for > >> consistency (3 instances)? > >> > >> Original: > >> Identification of the type of manifest is always by a Constrained > >> Application Protocol (CoAP) Content-Format integer [RFC7252]. > >> > >> The first item in the array of two MUST be an integer CoAP > >> Content-Format identifier. > >> > >> The identification of format is by CoAP Content Format, the same as > >> the "manifests" claim in Section 4.2.15. > >> > >> Perhaps: > >> Identification of the type of manifest is always by a Constrained > >> Application Protocol (CoAP) Content-Format identifier [RFC7252]. > >> > >> The first item in the array of two MUST be a CoAP Content-Format > >> identifier. > >> > >> The format is identified by a CoAP Content-Format identifier, which > >> is the same for the "manifests" claim in Section 4.2.15. > >> --> > >> > >> > >> 15) <!--[rfced] Section 4.2.16. What words are missing after "a"? > >> > >> Original: > >> This claim can be a [RFC9393]. > >> > >> Perhaps: > >> This claim can be a CoSWID [RFC9393]. > >> --> > >> > >> > >> 16) <!--[rfced] Section 4.2.17. Should the terms/values listed in these > >> two paragraphs match for consistency as shown below? > >> > >> Also, 'success/fail' or 'success/failure' is a corresponding pair > >> rather than 'successful/fail'. (If this is updated, seemingly the > >> CDDL below and in Section 7.3.1 would also need an update, e.g., > >> 'comparison-successful'.) > >> > >> Current: > >> This claim provides a simple standard way to report the result > >> of a comparison as success, failure, fail to run, and absence. > >> > >> > >> 1 - comparison successful: The comparison to reference values was > >> successful. > >> > >> 2 - comparison fail: The comparison was completed but did not > >> compare correctly to the reference values. > >> > >> 3 - comparison not run: The comparison was not run. This includes > >> error conditions such as running out of memory. > >> > >> 4 - measurement absent: The particular measurement was not > >> available for comparison. > >> > >> Perhaps: > >> This claim provides a simple standard way to report the result > >> of a comparison as a success, a failure, not run, or absent. > >> > >> > >> 1 - comparison success: The comparison to reference values was > >> successful. > >> > >> 2 - comparison failure: The comparison was completed but did not > >> compare correctly to the reference values. > >> > >> 3 - comparison not run: The comparison was not run. This includes > >> error conditions such as running out of memory. > >> > >> 4 - measurement absent: The particular measurement was not > >> available for comparison. > >> --> > >> > >> > >> 17) <!--[rfced] Sections 4.2.18.1 and 4.2.18.3. Would it be correct to say > >> that the keys (or no keys) are distinct from the surrounding > >> token produced by the attester? > >> > >> Original: > >> The Claims-Set type provides a means of representing claims from a > >> submodule that does not have its own attesting environment, i.e., it > >> has no keys distinct from the attester producing the surrounding > >> token. > >> > >> The CBOR-Nested-Token and JSON-Selector types provide a means of > >> representing claims from a submodule that has its own attesting > >> environment, i.e., it has keys distinct from the attester producing > >> the surrounding token. > >> > >> Perhaps: > >> The Claims-Set type provides a means of representing claims from a > >> submodule that does not have its own attesting environment, i.e., it > >> has no keys that are distinct from the surrounding token produced by > >> the attester. > >> > >> The CBOR-Nested-Token and JSON-Selector types provide a means of > >> representing claims from a submodule that has its own attesting > >> environment, i.e., it has keys that are distinct from the > >> surrounding token produced by the attester. > >> --> > >> > >> > >> 18) <!--[rfced] Section 4.2.18.2. We updated this sentence to clarify > >> "is directly". If it changes the intended meaning, please let us know. > >> > >> Original: > >> The input to the digest algorithm is directly the CBOR or > >> JSON-encoded Claims-Set for the submodule. > >> > >> Current: > >> The direct input to the digest algorithm is either the > >> CBOR-encoded or the JSON-encoded Claims-Set for the > >> submodule. > >> --> > >> > >> > >> 19) <!--[rfced] Section 6.3.9. FYI, "end-end" has been updated to > >> "end-to-end". > >> (This is similar to a change that was made in version 31 of the original.) > >> > >> Original: > >> While not always possible, a profile should specify or make reference > >> to, a full end-end specification for key identification. > >> > >> Current: > >> While not always possible, a profile should specify, or make reference > >> to, a full end-to-end specification for key identification. > >> --> > >> > >> > >> 20) <!--[rfced] Section 6.3.12. The text mentions the measurement and > >> measurements claims; however, Section 4.2.16 only refers to the > >> "measurements" claim. Should "claims" perhaps be singular, or > >> should "measurement" be removed or updated (perhaps "measres" > >> claim was intended)? > >> > >> Original: > >> The "manifests" claim (Section 4.2.15) along with the > >> measurement and "measurements" (Section 4.2.16) claims are examples > >> of this, allowing the use of CoSWID and other formats. > >> > >> Perhaps: > >> The "manifests" claim (Section 4.2.15) along with the > >> "measurements" claim (Section 4.2.16) and "measres" claim (Section 4.2.17) > >> are examples of this, allowing the use of CoSWID and other formats. > >> --> > >> > >> > >> 21) <!--[rfced] Section 6.3.12. FYI - We updated the following text as the > >> second sentence is a fragment. If this changes the intended > >> meaning, please let us know. > >> > >> Original: > >> For example, there are variations in the CoSWID format. A profile > >> that require the receiver to accept all variations that are allowed > >> to be sent. > >> > >> Current: > >> For example, there are variations in the CoSWID format, such as a profile > >> that requires the receiver to accept all variations that are allowed > >> to be sent. > >> --> > >> > >> > >> 22) <!--[rfced] Section 7.1. This sentence mentions that CDDL for the > >> seven claims is included "here". Please clarify what "here" > >> refers to - is it referring to Section 7.1 or to one of the > >> subsections? > >> > >> Original: > >> CDDL for the seven claims defined by [RFC8392] and [RFC7519] is > >> included here. > >> > >> Perhaps: > >> CDDL for the seven claims defined by [RFC8392] and [RFC7519] is > >> also specified in this document. > >> --> > >> > >> > >> 23) <!--[rfced] Section 7.2. What does "This" refer to - is it "The > >> following subsections" as shown below? > >> > >> Current: > >> 7.2. Encoding Data Types > >> > >> This makes use of the types defined in "Standard Prelude" > >> (Appendix D of [RFC8610]). > >> > >> Perhaps: > >> 7.2. Encoding Data Types > >> > >> The following subsections use the types defined in > >> "Standard Prelude" (Appendix D of [RFC8610]). > >> --> > >> > >> > >> 24) <!--[rfced] Section 7.3.1. This sentence does not parse - is "use" > >> perhaps missing after the comma? Please let us know how we may > >> update for clarity. > >> > >> Original: > >> When there is variation between CBOR and JSON, the > >> JC<> CDDL generic defined in Appendix D. > >> > >> Perhaps: > >> When there is variation between CBOR and JSON, use the > >> JC<> CDDL generic defined in Appendix D. > >> --> > >> > >> > >> 25) <!--[rfced] Section 9.1. The following text does not parse > >> (specifically, the latter part after the comma). Please let us > >> know how we may update for clarity. > >> > >> Original: > >> For example, this document says that a UEID is permanent and that it > >> must not change, but it does not say what degree of attack to change > >> it must be defended. > >> > >> Perhaps: > >> For example, this document states that a UEID is permanent and that it > >> must not change, but it does not state if change is needed to defend > >> against a certain degree of attack. > >> --> > >> > >> > >> 26) <!--[rfced] Section 10.2. Is this sentence necessary? > >> > >> Original: > >> The "Claim Value > >> Type(s)" here all name CDDL definitions and are only for the CWT > >> registry. > >> > >> It seems redundant with this text in the preceding paragraph: > >> > >> The "Claim Key" and "Claim Value Types(s)" are for the CWT registry > >> only. > >> --> > >> > >> > >> 27) <!--[rfced] Below are questions about the IANA-related text. > >> In addition to responding to these questions, please review > >> all of the IANA-related updates carefully and let us know > >> if any further updates are needed. > >> > >> a) Section 4.2.18.2. Please clarify which IANA registry is > >> being referred to in the last sentence (i.e., the "JOSE Algorithm > >> registry"). Is it the "JSON Web Signature and Encryption > >> Algorithms" registry <https://www.iana.org/assignments/jose/>? > >> <https://www.iana.org/assignments/jose/>?> > >> > >> Original: > >> The hash algorithm identifier is always from the COSE > >> Algorithm registry, [IANA.COSE.Algorithms]. Either the integer or > >> string identifier may be used. The hash algorithm identifier is > >> never from the JOSE Algorithm registry. > >> > >> Perhaps: > >> The hash algorithm identifier is always from the "COSE Algorithms" > >> registry [IANA.COSE.Algorithms]. Either the integer or > >> the string identifier may be used. The hash algorithm identifier is > >> never from the "JSON Web Signature and Encryption Algorithms" registry. > >> > >> b) Section 10.2. May we remove all quote marks from the JWT Claim Name > >> fields? We note that quote marks are not used in the "CBOR Web Token > >> (CWT) Claims" registry <https://www.iana.org/assignments/cwt> > >> <https://www.iana.org/assignments/cwt>>. > >> For example: > >> OLD: JWT Claim Name: "eat_nonce" > >> NEW: JWT Claim Name: eat_nonce > >> > >> c) Section 10.2. In the "CBOR Web Token (CWT) Claims" registry > >> for eat_nonce (Claim Key 10), the Reference field includes "OpenID > >> Connect Core 1.0" (https://openid.net/specs/openid-connect-core-1_0.html > >> <https://openid.net/specs/openid-connect-core-1_0.html>), > >> but the Reference field in the draft did not. FYI, this document > >> has been updated to match the registry, and "OpenID Connect Core 1.0" > >> has been added as an informative reference. > >> > >> In the JWT Claims registry, should "eat_nonce" have a matching > >> Reference field? (This document states the Reference fields are > >> "common and equivalent".) If so, we will ask IANA to update the registry > >> as follows. > >> > >> Old: eat_nonce Nonce [IETF] [RFC-ietf-rats-eat-30] > >> New: eat_nonce Nonce [IETF] [OpenID Connect Core 1.0][RFC-ietf-rats-eat-30] > >> > >> > >> d) Section 10.2. Regarding "Claim Description" (in both the CWT and JWT > >> Claims registries), would you like to update these to remove 'Indicates' > >> so they are similar to other descriptions? If so, we will ask IANA to > >> update the registries accordingly with any changes made. > >> > >> Original: > >> ueid The Universal Entity ID > >> > >> sueids Semi-permanent UEIDs > >> > >> hwmodel Model identifier for hardware > >> > >> dbgstat Indicates status of debug facilities > >> > >> eat_profile Indicates the EAT profile followed > >> > >> intuse Indicates intended use of the EAT > >> > >> Perhaps: > >> ueid Universal Entity ID > >> > >> sueids Semipermanent UEIDs > >> > >> hwmodel Model identifier for hardware > >> > >> dbgstat The status of debug facilities > >> > >> eat_profile The EAT profile followed > >> > >> intuse The intended use of the EAT > >> > >> e) Section 10.3. In the "DEV URN Subtypes" registry, may we > >> update the descriptions as follows? > >> - change "Identifier" to "ID" to match the "JSON Web Token Claims" > >> registry, "CBOR Web Token (CWT) Claims" registry, and the running text in > >> this document. > >> - change "Semi-permanent" to "Semipermanent" per Merriam-Webster > >> (throughout this document and in the two other registries). > >> > >> Original: > >> ueid Universal Entity Identifier > >> sueid Semi-permanent Universal Entity Identifier > >> > >> Perhaps: > >> ueid Universal Entity ID > >> sueid Semipermanent Universal Entity ID > >> > >> f) Section 10.4. FYI - In the "CBOR Tags" registry at > >> https://www.iana.org/assignments/cbor-tags/ > >> <https://www.iana.org/assignments/cbor-tags/>, the reference to Section 5 > >> of this document is included under the Semantics column. We will ask > >> IANA to update the registry so that "RFC 9711, Section 5" is only > >> in the Reference column. > >> > >> Original: > >> +=====+============+===============================+ > >> | Tag | Data Items | Semantics | > >> +=====+============+===============================+ > >> | 602 | array | Detached EAT Bundle Section 5 | > >> > >> Current: > >> +=====+===========+=====================+=====================+ > >> | Tag | Data Item | Semantics | Reference | > >> +=====+===========+=====================+=====================+ > >> | 602 | array | Detached EAT Bundle | RFC 9711, Section 5 | > >> > >> > >> g) Section 10.5. The columns for the "Entity Attestation Token > >> (EAT) Intended Uses" registry are "Integer", "Name", and > >> "Description" in this document, but "Value", "Description", and > >> "Reference" in the IANA registry <https://www.iana.org/assignments/rats> > >> <https://www.iana.org/assignments/rats>>. > >> Which one is correct? If the IANA registry is correct, please provide > >> updated text for Section 10.5 where it describes the three columns. > >> --> > >> > >> > >> 28) <!-- [rfced] FYI, a normative reference to RFC 5234 has been added > >> because > >> this document contains ABNF. See the IESG statement on "Guidelines for > >> the Use of Formal Languages in IETF Specifications" > >> (https://ietf.org/blog/guidelines-use-formal-languages-ietf-specifications/ > >> > >> <https://ietf.org/blog/guidelines-use-formal-languages-ietf-specifications/>) > >> - > >> specifically "The use of a language requires a reference to the > >> specification for that language. This reference is normative ..." > >> > >> Please review where RFC 5234 is cited and let us know if you prefer > >> otherwise. Also, RFC 7405 has been added because "%s" is used. > >> > >> Current: > >> The ABNF [RFC5234] [RFC7405] for these two URNs is as follows, > >> where b64ueid is the base64url-encoded binary byte string for > >> the UEID or SUEID: > >> > >> body =/ ueidbody > >> ueidbody = %s"ueid:" b64ueid > >> --> > >> > >> > >> 29) <!--[rfced] FYI, we updated the URL for this reference because it > >> was a direct download of the PDF file. The updated URL points to > >> a landing page with more information and the option to download > >> the file instead. Please let us know if you prefer otherwise. > >> > >> Original: > >> [WGS84] National Geospatial-Intelligence Agency (NGA), "WORLD GEODETIC > >> SYSTEM 1984, NGA.STND.0036_1.0.0_WGS84", 8 July 2014, > >> <https://earth-info.nga.mil/php/download.php?file=coord-wgs84> > >> <https://earth-info.nga.mil/php/download.php?file=coord-wgs84>>. > >> > >> Current: > >> [WGS84] National Geospatial-Intelligence Agency (NGA), "Department > >> of Defense World Geodetic System 1984: Its Definition and > >> Relationships with Local Geodetic Systems", > >> NGA.STND.0036_1.0.0_WGS84, July 2014, > >> <https://nsgreg.nga.mil/doc/view?i=4085> > >> <https://nsgreg.nga.mil/doc/view?i=4085>>. > >> --> > >> > >> > >> 30) <!--[rfced] FYI, we updated this reference to reflect the most current > >> version (September 2024). Please let us know if you prefer otherwise. > >> > >> Original: > >> [ThreeGPP.IMEI] > >> 3GPP, "3rd Generation Partnership Project; Technical Specification > >> Group Core Network and Terminals; Numbering, addressing and > >> identification", 2019, <https://portal.3gpp.org/desktopmodules/ > >> <https://portal.3gpp.org/desktopmodules/> > >> Specifications/SpecificationDetails.aspx?specificationId=729>. > >> > >> Current: > >> [ThreeGPP.IMEI] > >> 3GPP, "Numbering, addressing and identification", 3GPP > >> TS 23.003, Version 19, September 2024, > >> <https://portal.3gpp.org/desktopmodules/Specifications/ > >> <https://portal.3gpp.org/desktopmodules/Specifications/> > >> SpecificationDetails.aspx?specificationId=729>. > >> --> > >> > >> > >> 31) <!--[rfced] There is a more recent version of this reference > >> (September 2024). May we point to that version instead, or do you > >> prefer the 2013 (outdated) version? > >> > >> Current: > >> [W3C.GeoLoc] > >> Popescu, A., Ed., "Geolocation API Specification", W3C > >> Recommendation, 24 October 2013, > >> <https://www.w3.org/TR/2013/REC-geolocation-API- > >> <https://www.w3.org/TR/2013/REC-geolocation-API-> > >> 20131024/>. > >> > >> Perhaps: > >> [W3C.GeoLoc] > >> Cáceres, M. and R. Grant, "Geolocation", W3C > >> Recommendation, September 2024, > >> <https://www.w3.org/TR/geolocation/> > >> <https://www.w3.org/TR/geolocation/>>. > >> --> > >> > >> > >> 32) <!--[rfced] Appendix A. Please review this note and let us know if > >> there are any outstanding actions regarding regenerating the examples. > >> > >> AUTHOR NOTE: > >> RFC Editor: When the IANA values are permanently assigned, please > >> contact the authors so the examples can be regenerated. Regeneration > >> is required because IANA-assigned values are inside hex and based-64 > >> encoded data and some of these are signed. > >> --> > >> > >> > >> 33) <!--[rfced] Questions about the sourcecode > >> > >> a) We updated <artwork> to <sourcecode> in Sections 1 and 10.3 as > >> well as Appendices A.1.1 - A.2.3 and D. Please confirm that this is > >> correct. > >> > >> In addition, please 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/rpc/wiki/doku.php?id=sourcecode-types> > >> <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>>. > >> 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. > >> > >> ... > >> Sourcecode in the Appendices > >> > >> b) We notice that each sourcecode element in the appendices contains > >> introductory text, formatted as a comment within the sourcecode. Should > >> this > >> text be moved outside of the sourcecode? If not, please consider the > >> questions > >> that follow. > >> > >> c) Appendix A.2.1. The text below refers to a section that is > >> outside of the sourcecode. Should a pointer to "Appendix A.1.7 > >> of RFC 9711" be added? > >> > >> Original: > >> / This is a full CWT-format token. The payload is the / > >> / attestation hardware block above. The main structure / > >> / visible is that of the COSE_Sign1. / > >> > >> Perhaps: > >> / This is a full CWT-format token. The payload is the / > >> / attestation hardware block in Appendix A.1.7 of / > >> / RFC 9711. The main structure that is visible is / > >> / that of the COSE_Sign1. / > >> > >> d) Appendix A.2.2. The text below refers to "the next section". > >> Should a pointer be added to Appendix A.2.3? > >> > >> Original: > >> / Most importantly, it includes a submodule that is a / > >> / detached digest which is the hash of the "TEE" claims / > >> / set in the next section. > >> > >> e) Appendix D. The text below refers to the I-D > >> "draft-ietf-rats-uccs". May we move this sentence outside of > >> the sourcecode so that a citation can be added for the I-D? > >> > >> Original: > >> ; This is replicated from draft-ietf-rats-uccs > >> > >> Claims-Set = { > >> * $$Claims-Set-Claims > >> * Claim-Label .feature "extended-claims-label" => any... > >> > >> Perhaps: > >> The following example is replicated from [UCCS]. > >> > >> Claims-Set = { > >> * $$Claims-Set-Claims > >> * Claim-Label .feature "extended-claims-label" => any... > >> > >> f) Appendix D. Please clarify where a reader can find "claims-set.cddl" > >> as this is the only mention of it in this document. > >> > >> Original: > >> ; Note that the payload of a JWT is defined in claims-set.cddl. That > >> ; definition is common to CBOR and JSON. > >> --> > >> > >> > >> 34) <!--[rfced] Appendix A.1.2. To avoid repetition, we updated "with the > >> CPU" to "containing the CPU". Please review. > >> > >> Original: > >> The main attestation is associated with the chip with the > >> CPU and running the main OS. > >> > >> Current: > >> The main attestation is associated with the chip containing > >> the CPU and running the main OS. > >> --> > >> > >> > >> 35) <!--[rfced] Appendix A.1.3. Is the intention to say that 47 bytes are > >> encoded in CBOR "including" an 8-byte nonce and 16-byte UEID as > >> shown below? Please let us know how we may update for clarity. > >> > >> Original: > >> 47 bytes encoded in CBOR (8-byte nonce, 16-byte UEID). > >> > >> Perhaps: > >> 47 bytes are encoded in CBOR (including an 8-byte nonce and > >> a 16-byte UEID). > >> --> > >> > >> > >> 36) <!--[rfced] Appendix A.1.4. Within the sourcecode, may we update > >> "eliptic" to "elliptic" as shown below? If different spacing is > >> desired, please let us know. > >> > >> Original: > >> / kty / 1: 2, / EC2, eliptic curve with x & y / > >> > >> Perhaps: > >> / kty / 1: 2, / EC2, elliptic curve with x & y/ > >> --> > >> > >> > >> 37) <!--[rfced] Appendix A.1.6. We believe "Trustus Verifications" is a > >> service (rather than multiple services) that verifies the > >> software component measures, so we have updated accordingly. If > >> what is shown below is not correct, please let us know. > >> > >> Original: > >> "Trustus Verifications" is the name of the services that verifies the > >> software component measurements. > >> > >> Current: > >> "Trustus Verifications" is the name of the service that verifies the > >> software component measurements. > >> --> > >> > >> > >> 38) <!--[rfced] Appendix B.2. How can "UEID takes the view" be reworded > >> to avoid personification? Also, it is not clear what "It" refers to > >> in the second sentence - is it also "UEID"? Please clarify. > >> > >> Original: > >> UEID takes the view that this construction is no longer needed, in > >> particular because cryptographic-quality random number generators > >> are readily available. It takes the view that hardware, software, > >> and/or manufacturing processes implement UEID in a simple and > >> direct way. > >> --> > >> > >> > >> 39) <!--[rfced] Appendix C.4. We are having trouble parsing the first > >> sentence below. Please let us know how we may update for clarity. > >> > >> Original: > >> EAT thus cannot be defined permanence in terms of defense against > >> attack. EAT's definition of permanence is in terms of operations and > >> device lifecycle. > >> > >> Perhaps: > >> Thus, EAT's permanence cannot be defined in terms of defense against > >> attack; it can be defined in terms of operations and device life cycle. > >> --> > >> > >> > >> 40) <!--[rfced] Appendix E.3. May we rephrase this text for clarity? > >> Please let us know if this conveys the intended meaning. > >> > >> Original: > >> However, EAT is intended for use in low-security use cases > >> the same as high-security use case. > >> > >> Perhaps: > >> However, EAT is intended for use in both low-security and > >> high-security use cases. > >> --> > >> > >> > >> 41) <!-- [rfced] In the html and pdf outputs, the text enclosed in <tt> is > >> output > >> in fixed-width font. In the txt output, there are no changes to the font, > >> and the quotation marks have been removed. > >> > >> Please review carefully and let us know if the output is acceptable or if > >> any > >> updates are needed. > >> --> > >> > >> > >> 42) <!-- [rfced] Please review whether any of the notes in this document > >> should be in the <aside> element. It is defined as "a container for > >> content that is semantically less important or tangential to the > >> content that surrounds it" > >> (https://authors.ietf.org/en/rfcxml-vocabulary#aside > >> <https://authors.ietf.org/en/rfcxml-vocabulary#aside>). > >> --> > >> > >> > >> 43) <!-- [rfced] Throughout the text, the following terminology appears to > >> be used > >> inconsistently. Please review these occurrences and let us know if/how they > >> may be made consistent. > >> > >> Claims-Set (34) vs. claims set (8) > >> Claims-Sets (3) vs. claims-sets (1) vs. claims sets (11) > >> > >> Detached EAT Bundle vs. detached EAT bundle > >> [Note: should all instances be capitalized to match how it > >> appears in the "CBOR Tags" registry > >> (https://www.iana.org/assignments/cbor-tags > >> <https://www.iana.org/assignments/cbor-tags>)?] > >> > >> EAT nonce claim vs. "eat_nonce" claim > >> [Note: are these different or should they be consistent? One instance > >> mentions "EAT nonce claim" but points to Section 4.1, which discusses > >> the "eat_nonce" claim: > >> One option to provide freshness is the EAT nonce claim (Section 4.1). > >> > >> "Nonce" claim vs. "nonce" claim vs. nonce claim > >> Key ID vs. key ID vs. key identifier > >> Simple TEE vs. simple TEE > >> Submodule claim vs. submodule claim > >> > >> b) FYI - We updated the following terms for consistency. Please let us > >> know > >> if any further updates are needed. > >> > >> base-64 and base 64 -> base64 > >> Canonical -> canonical > >> CWT Tag -> CWT tag (per RFC 8392) > >> Collision Probability -> collision probability > >> EAT Claims -> EAT claims > >> eco-system -> ecosystem > >> Simple TEE -> simple TEE > >> standards-action -> Standards Action (per RFC 8126) > >> Hexadecimal Representation -> hexadecimal representation (per other RFCs) > >> > >> The following terms are capitalized in RFC 9334; however, they were > >> typically lowercased outside Section 2 of this document. > >> > >> Attester (1 instance) -> attester > >> Endorser (1 instance) -> endorser > >> Evidence (1 instance) -> evidence > >> > >> c) Should "nested token" be "Nested-Token" in the following since the text > >> seems to be referring to the type, or is it correct per the context? > >> > >> Current: > >> This CDDL uses, but does not define, Submodule or nested tokens > >> because the definition for these types varies between CBOR and JSON > >> and the JC<> generic cannot be used to define it. > >> > >> The value of each entry in a submodule may be a Claims-Set, nested token, > >> or Detached-Submodule-Digest. > >> --> > >> > >> > >> 44) <!-- [rfced] Abbreviations > >> > >> a) We have added expansions for the following abbreviations > >> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > >> expansion in the document carefully to ensure correctness. > >> > >> Company ID (CID) > >> Concise Software Identification (CoSWID) > >> Certificate Revocation List (CRL) > >> Elliptic Curve Digital Signature Algorithm (ECDSA) > >> Extended Unique Identifier (EUI) > >> Global Navigation Satellite System (GNSS) > >> Global System for Mobile Communications Association (GSMA) > >> Hashed Message Authentication Code (HMAC) > >> hardware (HW) > >> Initial Device Identifier (IDevID) > >> Internet of Things (IoT) > >> JSON Web Encryption (JWE) > >> JSON Web Signature (JWS) > >> Local Device Identifier (LDevID) (per IEEE.802.1AR) > >> Media Access Control (MAC) > >> Not a Number (NaN) > >> Organizationally Unique Identifier (OUI) > >> Software Version Number (SVN) > >> software (SW) > >> Software Identification (SWID) > >> > >> b) FYI, we updated this expansion to match use in past RFCs. > >> > >> JavaScript Object Signing and Encryption (JOSE) (this document) vs. > >> JSON Object Signing and Encryption (JOSE) (in RFC 9052 and many other RFCs) > >> --> > >> > >> > >> 45) <!-- [rfced] Please review the "Inclusive Language" portion of the > >> online > >> Style Guide > >> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > >> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>> > >> and let us know if any changes are needed. > >> > >> For example, please consider whether the following terms should be > >> updated: > >> - whitespace > >> - master > >> - Native > >> --> > >> > >> > >> Thank you. > >> > >> RFC Editor/kc/ar > >> > >> > >> > >> On Mon, Jan 13, 2025 at 8:48 PM <rfc-edi...@rfc-editor.org > >> <mailto:rfc-edi...@rfc-editor.org>> wrote: > >> *****IMPORTANT***** > >> > >> Updated 2025/01/13 > >> > >> RFC Author(s): > >> -------------- > >> > >> Instructions for Completing AUTH48 > >> > >> Your document has now entered 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 > >> available as listed in the FAQ (https://www.rfc-editor.org/faq/ > >> <https://www.rfc-editor.org/faq/>). > >> > >> 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 > >> <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> > >> <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 > >> > >> * rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org> (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). > >> > >> * auth48archive@rfc-editor.org <mailto:auth48archive@rfc-editor.org>, > >> which is a new archival mailing list > >> to preserve AUTH48 conversations; it is not an active discussion > >> list: > >> > >> * More info: > >> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > >> > >> <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc> > >> > >> * The archive itself: > >> https://mailarchive.ietf.org/arch/browse/auth48archive/ > >> <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, > >> auth48archive@rfc-editor.org <mailto:auth48archive@rfc-editor.org> 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/rfc9711.xml > >> <https://www.rfc-editor.org/authors/rfc9711.xml> > >> https://www.rfc-editor.org/authors/rfc9711.html > >> <https://www.rfc-editor.org/authors/rfc9711.html> > >> https://www.rfc-editor.org/authors/rfc9711.pdf > >> <https://www.rfc-editor.org/authors/rfc9711.pdf> > >> https://www.rfc-editor.org/authors/rfc9711.txt > >> <https://www.rfc-editor.org/authors/rfc9711.txt> > >> > >> Diff file of the text: > >> https://www.rfc-editor.org/authors/rfc9711-diff.html > >> <https://www.rfc-editor.org/authors/rfc9711-diff.html> > >> https://www.rfc-editor.org/authors/rfc9711-rfcdiff.html > >> <https://www.rfc-editor.org/authors/rfc9711-rfcdiff.html> (side by side) > >> > >> Diff of the XML: > >> https://www.rfc-editor.org/authors/rfc9711-xmldiff1.html > >> <https://www.rfc-editor.org/authors/rfc9711-xmldiff1.html> > >> > >> > >> Tracking progress > >> ----------------- > >> > >> The details of the AUTH48 status of your document are here: > >> https://www.rfc-editor.org/auth48/rfc9711 > >> <https://www.rfc-editor.org/auth48/rfc9711> > >> > >> Please let us know if you have any questions. > >> > >> Thank you for your cooperation, > >> > >> RFC Editor > >> > >> -------------------------------------- > >> RFC9711 (draft-ietf-rats-eat-31) > >> > > Title : The Entity Attestation Token (EAT) > > Author(s) : L. Lundblade, G. Mandyam, J. O'Donoghue, C. Wallace > > WG Chair(s) : Ned Smith, Nancy Cam-Winget, Kathleen Moriarty > > Area Director(s) : Deb Cooley, Paul Wouters > > <RFC 9711 Editor Feedback v0.1.docx>-- > > auth48archive mailing list -- auth48archive@rfc-editor.org > > <mailto:auth48archive@rfc-editor.org> > > To unsubscribe send an email to auth48archive-le...@rfc-editor.org > > <mailto:auth48archive-le...@rfc-editor.org> > > > > <RFC 9711 Editor Feedback v0.2.docx> > > > > > > > > > > <RFC 9711 Editor Feedback v0.4.docx> -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
