Yes, looks great. Thank you! Yes, I approve for publication.
LL > On Feb 20, 2025, at 12:03 PM, Karen Moore <kmo...@staff.rfc-editor.org> wrote: > > Hi Laurence, > > Thank you for your comment. We have made the suggested updates; please see > the changes in our updated files. We have also noted your approval of the > document (we will assume your assent to any further changes made by your > coauthors or the AD unless we hear objection at that time). > > We now await further changes, if needed, and approvals from your coauthors > and the AD. Once approvals are received, we will ask IANA to update their > registries accordingly. > > —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 > > Best regards, > RFC Editor/kc > >> On Feb 20, 2025, at 10:09 AM, lgl securitytheory.com >> <l...@securitytheory.com> wrote: >> >> 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
