Hi Carl, Thank you for the catch. We have updated "$EAT-CBOR-Tagged-Token” to "$CBOR-Tagged-Token” in Section 3.
—Files (please refresh)— The updated XML file is here: 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.pdf 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-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-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-rfcdiff.html (side by side) Best regards, RFC Editor/kc > On Feb 7, 2025, at 2:33 PM, Carl Wallace <c...@redhoundsoftware.com> wrote: > > 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