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 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 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) This diff file shows all changes made to date: 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> > 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> >> 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> >> 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), 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>. >> > 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 >> >> 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) >> >> This diff file shows all changes made to date: >> 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 >> >> Thank you, >> RFC Editor/kc >> >> >> > On Jan 22, 2025, at 7:54 AM, Giridhar Mandyam via auth48archive >> > <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> 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), 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>. >> > >> > >> > 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/>. >> > --> >> > >> > >> > 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/>? >> > >> > 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>. >> > 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), >> > 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/, 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>. >> > 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/) >> > - >> > 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>. >> > >> > 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>. >> > --> >> > >> > >> > 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/ >> > 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/ >> > 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- >> > 20131024/>. >> > >> > Perhaps: >> > [W3C.GeoLoc] >> > Cáceres, M. and R. Grant, "Geolocation", W3C >> > Recommendation, September 2024, >> > <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>. >> > 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). >> > --> >> > >> > >> > 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)?] >> > >> > 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> >> > 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> 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/). >> > >> > 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). >> > >> > * 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>. >> > >> > * 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 (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, 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 >> > >> > * The archive itself: >> > 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 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.html >> > https://www.rfc-editor.org/authors/rfc9711.pdf >> > 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-rfcdiff.html (side by side) >> > >> > Diff of the XML: >> > 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 >> > >> > 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 >> > To unsubscribe send an email to auth48archive-le...@rfc-editor.org >> >> <RFC 9711 Editor Feedback v0.2.docx> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
