Hi Karen, I did a full review again. I’m ready to sign off, except we (well I) didn’t get the last little change right.
The terminology section is actually divided by reference source(s) by one-sentence paragraphs that reference the source documents. So there was already a reference to RFC 9334 and the one we just added should be removed. Also the sentence about EAT not capitalizing should move to the one-sentence paragraph (which will now be two sentences) that references 9334 because it only applies to RATS terminology. Sorry I didn’t get that right. I really do think that is the last change. Thanks for all the work! Really do appreciate it making the document better! LL > On Feb 19, 2025, at 1:52 PM, Karen Moore <kmo...@staff.rfc-editor.org> wrote: > > Hi Laurence, > > We have inserted the suggested sentence and updated the definitions of > "base64url encoding”, “Relying Party”, and “Reference Values” to match the > text in the RFCs referenced. If other terms need to be updated, please > provide the Old/New text. > > —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 (5): > 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) > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9711 > > We will await approvals from each author and the AD prior to moving forward > with publication. > > Best regards, > RFC Editor/kc > > >> On Feb 19, 2025, at 11:14 AM, lgl securitytheory.com >> <l...@securitytheory.com> wrote: >> >> Hi Karen, >> >> We’d like to use the exactly the same exact as the terminology definition >> sources, but not capitalize the RATS terms like “evidence." That gives >> consistency in the EAT document which we think is better for the reader. >> >> We’d also like to add this sentence to the end of the paragraph that starts >> with "This document reuses terminology from…" >> >> Note that EAT does not capitalize RATS terms like “evidence” for easier >> readability. >> >> Thanks! >> >> LL >> >> >>> On Feb 18, 2025, at 4:36 PM, Karen Moore <kmo...@staff.rfc-editor.org> >>> wrote: >>> >>> Dear Giri and *Roman (AD), >>> >>> *Roman, we are awaiting your approval of the following sections/appendices >>> (note that we have added "Appendix C" to the list): 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, C, and D. Please see the changes in >>> <https://www.rfc-editor.org/authors/rfc9711-auth48diff.html> and some >>> author explanations in the attached Word doc. >>> >>> Giri, thank you for providing the document that outlines round 5 of the >>> suggested changes. Our files reflect these updates, except for item #3 - >>> please see our questions below. >>> >>> 1) Regarding the request below, we note that the text in >>> draft-ietf-rats-eat-31 does not exactly match the terminology definitions >>> in the referenced documents. We believe the terms listed below are in >>> question - please let us know if any other terms need to be reviewed. >>> >>> Note: For consistency, the “Perhaps” text reflects the choices the authors >>> made regarding the capitalization of terms throughout the document (for >>> example, lowercase “attester”, “evidence”, and “reference value”). If >>> further changes are desired, please let us know. >>> >>>> 3) Please revert the terminology definitions in Section 2 back to their >>>> original wording in Draft -31. The terminology definitions in section 2 >>>> were copied exactly from the named RFC sources, and it is important that >>>> independent readers not come away with the impression that the EAT editors >>>> or the RATS WG changed definitions that have already been provided in >>>> prior RFC’s. >>> >>> a) base64url encoding >>> >>> From RFC 7515: >>> Base64url Encoding >>> Base64 encoding using the URL- and filename-safe character set >>> defined in Section 5 of RFC 4648 [RFC4648], with all trailing '=' >>> characters omitted (as permitted by Section 3.2) and without the >>> inclusion of any line breaks, whitespace, or other additional >>> characters. >>> >>> From draft-ietf-rats-eat-31: >>> 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 the >>> URL- and filename-safe character set defined in Section 5 of [RFC4648], >>> with all trailing '=' characters omitted and without the inclusion of >>> any line >>> breaks, whitespace, or other additional characters. >>> >>> ... >>> b) Relying Party >>> >>> From RFC 9334: >>> Relying Party: A role performed by an entity that depends on the >>> validity of information about an Attester for purposes of reliably >>> applying application-specific actions. Compare: relying party [RFC4949]. >>> >>> From draft-ietf-rats-eat-31: >>> Relying Party: A role that depends on the validity of information >>> about an attester, for purposes of reliably applying application >>> specific actions. Compare /relying party/ in [RFC4949]. >>> >>> Perhaps: >>> Relying Party: A role performed by an entity that depends on the >>> validity of information about an attester for purposes of reliably >>> applying application-specific actions. Compare: relying party [RFC4949]. >>> >>> ... >>> c) Reference Values >>> >>> From RFC 9334: >>> Reference Values: A set of values against which values of Claims can >>> be compared as part of applying an Appraisal Policy for Evidence. >>> Reference Values are sometimes referred to in other documents as >>> "known-good values", "golden measurements", or "nominal values”. >>> These terms typically assume comparison for equality, whereas here, >>> Reference Values might be more general and be used in any sort of >>> comparison. >>> >>> From draft-ietf-rats-eat-31: >>> Reference Values: A set of values against which values of claims can >>> be compared as part of applying an appraisal policy for evidence. >>> Reference Values are sometimes referred to in other documents as >>> known-good values, golden measurements, or nominal values, >>> although those terms typically assume comparison for equality, >>> whereas here reference values might be more general and be >>> used in any sort of comparison. >>> >>> Perhaps: >>> Reference Values: A set of values against which values of claims can >>> be compared as part of applying an appraisal policy for evidence. >>> Reference values are sometimes referred to in other documents as >>> "known-good values", "golden measurements", or "nominal values”. >>> These terms typically assume comparison for equality, whereas here, >>> reference values might be more general and be used in any sort of >>> comparison. >>> >>> >>> —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 >>> (5): >>> 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 14, 2025, at 9:09 PM, Giridhar Mandyam <giridhar.mand...@gmail.com> >>>> wrote: >>>> >>>> Dear RFC Ed, >>>> >>>> Please see enclosed. The editors have found a few more editorial items >>>> that need to be addressed. >>>> >>>> @Roman Danyliw , if you would like to meet with the editors to discuss >>>> these items before publication then please let us know and we can set up a >>>> call. >>>> >>>> -Giri >>>> >>>> On Fri, Feb 14, 2025 at 11:10 AM Karen Moore <kmo...@staff.rfc-editor.org> >>>> wrote: >>>> Dear Roman (AD), >>>> >>>> We do not believe we have heard from you regarding the approval of the >>>> changes to several sections in the document. 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. >>>> 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 >>>> >>>> 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:47 PM, Karen Moore <kmo...@staff.rfc-editor.org> >>>>> wrote: >>>>> >>>>> 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> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> <RFC 9711 Editor Feedback v0.5.docx> >>> >>> <RFC 9711 Editor Feedback v0.5.docx> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
