The Entity Attestation Token (EAT)
draft-ietf-rats-eat-31
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-09-06
|
31 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-31.txt |
2024-09-06
|
31 | (System) | New version approved |
2024-09-06
|
31 | (System) | Request for posting confirmation emailed to previous authors: Carl Wallace , Giridhar Mandyam , Jeremy O'Donoghue , Laurence Lundblade |
2024-09-06
|
31 | Giridhar Mandyam | Uploaded new revision |
2024-08-05
|
30 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2024-08-02
|
30 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2024-08-02
|
30 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2024-08-02
|
30 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-30.txt |
2024-08-02
|
30 | (System) | New version approved |
2024-08-02
|
30 | (System) | Request for posting confirmation emailed to previous authors: Carl Wallace , Giridhar Mandyam , Jeremy O'Donoghue , Laurence Lundblade |
2024-08-02
|
30 | Giridhar Mandyam | Uploaded new revision |
2024-07-26
|
29 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2024-07-26
|
29 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2024-07-11
|
29 | Cindy Morgan | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2024-07-09
|
29 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2024-07-08
|
29 | (System) | RFC Editor state changed to EDIT |
2024-07-08
|
29 | (System) | IANA Action state changed to In Progress from RFC-Ed-Ack |
2024-07-08
|
29 | (System) | Removed all action holders (IESG state changed) |
2024-07-08
|
29 | Jenny Bui | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2024-07-08
|
29 | Jenny Bui | IESG has approved the document |
2024-07-08
|
29 | Jenny Bui | Closed "Approve" ballot |
2024-07-08
|
29 | Jenny Bui | Ballot approval text was generated |
2024-07-08
|
29 | Roman Danyliw | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2024-07-08
|
29 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-29.txt |
2024-07-08
|
29 | (System) | New version approved |
2024-07-08
|
29 | (System) | Request for posting confirmation emailed to previous authors: Carl Wallace , Giridhar Mandyam , Jeremy O'Donoghue , Laurence Lundblade |
2024-07-08
|
29 | Giridhar Mandyam | Uploaded new revision |
2024-06-25
|
28 | (System) | Changed action holders to Roman Danyliw (IESG state changed) |
2024-06-25
|
28 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2024-06-25
|
28 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-28.txt |
2024-06-25
|
28 | (System) | New version approved |
2024-06-25
|
28 | (System) | Request for posting confirmation emailed to previous authors: Carl Wallace , Giridhar Mandyam , Jeremy O'Donoghue , Laurence Lundblade |
2024-06-25
|
28 | Giridhar Mandyam | Uploaded new revision |
2024-06-24
|
27 | Roman Danyliw | Please review the IESG ballot feedback |
2024-06-24
|
27 | (System) | Changed action holders to Laurence Lundblade, Carl Wallace, Giridhar Mandyam, Jeremy O'Donoghue (IESG state changed) |
2024-06-24
|
27 | Roman Danyliw | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::AD Followup |
2024-06-20
|
27 | Jenny Bui | IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation |
2024-06-20
|
27 | Orie Steele | [Ballot Position Update] New position, Yes, has been recorded for Orie Steele |
2024-06-20
|
27 | Deb Cooley | [Ballot comment] I agree with Paul Wouter's comments: 1. on references to certification sources in 4.2.14 (this should be easy for Common Criteria) 2. random … [Ballot comment] I agree with Paul Wouter's comments: 1. on references to certification sources in 4.2.14 (this should be easy for Common Criteria) 2. random quality based directly off the hardware randomizers in Appendix B.2. Although, my rationale for this comment is slightly different. Classically a system uses a combination of hardware and software combiners and conditioners. Good quality random data should be taken from the combination vice directly from the hardware. While this may mask hardware failures, it definitely produces data that is smoother. My suspicion is that this is what was meant, so a slight tweak in the sentence should clarify it. In addition, I have this one nit: Section 4.2.1.1, para 8: produce/product? and 'another type for other' add the word 'items' to the end? |
2024-06-20
|
27 | Deb Cooley | Ballot comment text updated for Deb Cooley |
2024-06-20
|
27 | Deb Cooley | [Ballot comment] I agree with Paul Wouter's comments on references to certification sources (this should be easy for Common Criteria), and his comments about random … [Ballot comment] I agree with Paul Wouter's comments on references to certification sources (this should be easy for Common Criteria), and his comments about random quality based off of the hardware randomizers. In addition, I have this one nit: Section 4.2.1.1, para 8: produce/product? and 'another type for other' add the word 'items' to the end? |
2024-06-20
|
27 | Deb Cooley | [Ballot Position Update] New position, No Objection, has been recorded for Deb Cooley |
2024-06-19
|
27 | Murray Kucherawy | [Ballot comment] I balloted No Objection on -21, and the delta between that and this raises no new issues for me (and thanks for taking … [Ballot comment] I balloted No Objection on -21, and the delta between that and this raises no new issues for me (and thanks for taking my comments last time). |
2024-06-19
|
27 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2024-06-19
|
27 | Paul Wouters | [Ballot comment] Some very minor comments only: The claims set includes a nonce or some other means to assure freshness Does … [Ballot comment] Some very minor comments only: The claims set includes a nonce or some other means to assure freshness Does this mean "includes a received nonce from the verifier to assure freshness" ? as in the device itself doesn't generate the nonce right? Examples of certifications represented by a DLOA include those issued by Global Platform and those based on Common Criteria. Should there be an informative reference added for Global Platform and Common Criteria ? Today, cryptographic-quality random numbers are available from common CPUs and hardware. This hardware was introduced between 2010 and 2015. Operating systems and cryptographic libraries give access to this hardware. Consequently, there is little need for implementations to construct such random values from multiple sources on their own. I disagree with this claim. Hardware can become faulty. RNG generators could contain a backdoor by being seeding with known seed. This is why the Linux kernel random subsystem takes various sources and mixes the random in an entropy pool, and does not really allow direct hardware rng access. |
2024-06-19
|
27 | Paul Wouters | [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters |
2024-06-19
|
27 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2024-06-19
|
27 | Warren Kumari | [Ballot comment] I've said it before, an' I'll say it again: No Objection. (https://mailarchive.ietf.org/arch/msg/rats/YLQ3WLwFiMFqb-7nWFXdbQZR2O0/) |
2024-06-19
|
27 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2024-06-19
|
27 | Francesca Palombini | [Ballot comment] Thank you for the work on this document, which despite its length I found very clear and an easy read. Kudos to the … [Ballot comment] Thank you for the work on this document, which despite its length I found very clear and an easy read. Kudos to the authors and the working group. I didn't have a chance to review the doc when it passed IESG for the first time, so a couple of minor nits and comments. Section 4.2.15. > The second item is MUST be the actual manifest. s/is MUST/MUST Section 4.3.3. > 5 possible values for "intuse" are currently defined, but an IANA registry can be created in the future to extend these values based on new use cases of EAT. I would have created this registry already in this document. I trust that the wg has discussed this and decided against it? Section 10.1. > All new EAT claims defined subsequently should be placed in both registries. why not shall (or must) instead of should here? |
2024-06-19
|
27 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
2024-06-18
|
27 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2024-06-18
|
27 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2024-06-17
|
27 | Jim Guichard | [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard |
2024-06-15
|
27 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2024-06-13
|
27 | Roman Danyliw | [Ballot comment] Note: this document is returning for a second IESG Review. -24 was previously approved and sent to the RFC Editor. It was pulled … [Ballot comment] Note: this document is returning for a second IESG Review. -24 was previously approved and sent to the RFC Editor. It was pulled from the RFC Editor queue to remove a dependency causing a MISREF that was not likely to resolve in the near future. This document saw a new WG and IETF LC to confirm consensus on this approach. See IESG Write-Up for more details. |
2024-06-13
|
27 | Roman Danyliw | Ballot comment text updated for Roman Danyliw |
2024-06-13
|
27 | Roman Danyliw | Telechat date has been changed to 2024-06-20 from 2023-09-07 |
2024-06-13
|
27 | Roman Danyliw | Ballot has been issued |
2024-06-13
|
27 | Roman Danyliw | [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw |
2024-06-13
|
27 | Roman Danyliw | Created "Approve" ballot |
2024-06-13
|
27 | Roman Danyliw | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2024-06-13
|
27 | Roman Danyliw | Ballot writeup was changed |
2024-06-11
|
27 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2024-06-10
|
27 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2024-06-10
|
27 | David Dong | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-rats-eat-27; we had previously reviewed draft-ietf-rats-eat-21 as well. If any part of this … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-rats-eat-27; we had previously reviewed draft-ietf-rats-eat-21 as well. If any part of this review is inaccurate, please let us know. IANA understands that, upon approval of this document, there are four actions which we must complete. First, in the JSON Web Token Claims registry in the JSON Web Token (JWT) registry group located at: https://www.iana.org/assignments/jwt/ the following JWT Claim Names registrations have already been completed during the previous publication process; their references will be changed to [ RFC-to-be ]: JWT Claim Name: eat_nonce JWT Claim Name: ueid JWT Claim Name: sueids JWT Claim Name: oemid JWT Claim Name: hwmodel JWT Claim Name: hwversion JWT Claim Name: oemboot JWT Claim Name: dbgstat JWT Claim Name: location JWT Claim Name: eat_profile JWT Claim Name: submods JWT Claim Name: uptime JWT Claim Name: bootcount JWT Claim Name: bootseed JWT Claim Name: dloas JWT Claim Name: swname JWT Claim Name: swversion JWT Claim Name: manifests JWT Claim Name: measurements JWT Claim Name: measres JWT Claim Name: intuse Second, in the CBOR Web Token (CWT) Claims registry located at: https://www.iana.org/assignments/cwt/ the following CBOR Web Token (CWT) Claims registrations have already been completed during the previous publication process; their references will be changed to [ RFC-to-be ]: CBOR Claim Name: nonce CBOR Claim Key: 10 CBOR Claim Name: UEID CBOR Claim Key: 256 CBOR Claim Name: SUEIDs CBOR Claim Key: 257 CBOR Claim Name: Hardware OEM ID CBOR Claim Key: 258 CBOR Claim Name: Hardware Model CBOR Claim Key: 259 CBOR Claim Name: Hardware Version CBOR Claim Key: 260 CBOR Claim Name: Uptime CBOR Claim Key: 261 CBOR Claim Name: OEM Authorized Boot CBOR Claim Key: 262 CBOR Claim Name: Debug Status CBOR Claim Key: 263 CBOR Claim Name: Location CBOR Claim Key: 264 CBOR Claim Name: EAT Profile CBOR Claim Key: 265 CBOR Claim Name: Submodules Section CBOR Claim Key: 266 CBOR Claim Name: Uptime CBOR Claim Key: 261 CBOR Claim Name: Boot Count CBOR Claim Key: 267 CBOR Claim Name: Boot Seed CBOR Claim Key: 268 CBOR Claim Name: DLOAs CBOR Claim Key: 269 CBOR Claim Name: Software Name CBOR Claim Key: 270 CBOR Claim Name: Software Version CBOR Claim Key: 271 CBOR Claim Name: Software Manifests CBOR Claim Key: 272 CBOR Claim Name: Measurements CBOR Claim Key: 273 CBOR Claim Name: Software Measurement Results CBOR Claim Key: 274 CBOR Claim Name: Intended Use CBOR Claim Key: 275 Third, in the DEV URN Subtypes registry on the Device Identification registry group located at: https://www.iana.org/assignments/device-identification/ the following two DEV URN Subtypes registrations have already been completed during the previous publication process; their references will be changed to [ RFC-to-be ]: Subtype: ueid Description: Universal Entity Identifier Subtype: sueid Description: Semi-permanent Universal Entity Identifier Fourth, in the CBOR Tags registry on the Concise Binary Object Representation (CBOR) Tags registry group located at: https://www.iana.org/assignments/cbor-tags/ the following CBOR Tag registration has already been completed during the previous publication process; its reference will be changed to [ RFC-to-be ]: Tag: 602 Dfata Items: array Semantics: Detached EAT Bundle [ RFC-to-be; Section 5 ] We understand that these are the only actions required to be completed upon approval of this document. NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. For definitions of IANA review states, please see: https://datatracker.ietf.org/help/state/draft/iana-review Thank you, David Dong IANA Services Sr. Specialist |
2024-06-10
|
27 | Linda Dunbar | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Linda Dunbar. Sent review to list. |
2024-05-30
|
27 | Carlos Pignataro | Request for Last Call review by OPSDIR is assigned to Linda Dunbar |
2024-05-28
|
27 | Jenny Bui | The following Last Call announcement was sent out (ends 2024-06-11): From: The IESG To: IETF-Announce CC: draft-ietf-rats-eat@ietf.org, ned.smith@intel.com, rats-chairs@ietf.org, rats@ietf.org, rdd@cert.org … The following Last Call announcement was sent out (ends 2024-06-11): From: The IESG To: IETF-Announce CC: draft-ietf-rats-eat@ietf.org, ned.smith@intel.com, rats-chairs@ietf.org, rats@ietf.org, rdd@cert.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (The Entity Attestation Token (EAT)) to Proposed Standard The IESG has received a request from the Remote ATtestation ProcedureS WG (rats) to consider the following document: - 'The Entity Attestation Token (EAT)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2024-06-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract An Entity Attestation Token (EAT) provides an attested claims set that describes state and characteristics of an entity, a device like a smartphone, IoT device, network equipment or such. This claims set is used by a relying party, server or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rats-eat/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc9334: Remote ATtestation procedureS (RATS) Architecture (Informational - Internet Engineering Task Force (IETF)) |
2024-05-28
|
27 | Jenny Bui | IESG state changed to In Last Call from Last Call Requested |
2024-05-28
|
27 | Jenny Bui | Last call announcement was generated |
2024-05-28
|
27 | Jenny Bui | Last call announcement was generated |
2024-05-28
|
27 | Roman Danyliw | Last call was requested |
2024-05-28
|
27 | Roman Danyliw | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2024-05-26
|
27 | (System) | Changed action holders to Roman Danyliw (IESG state changed) |
2024-05-26
|
27 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2024-05-26
|
27 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-27.txt |
2024-05-26
|
27 | (System) | New version approved |
2024-05-26
|
27 | (System) | Request for posting confirmation emailed to previous authors: Carl Wallace , Giridhar Mandyam , Jeremy O'Donoghue , Laurence Lundblade |
2024-05-26
|
27 | Giridhar Mandyam | Uploaded new revision |
2024-05-23
|
26 | Roman Danyliw | AD Review: https://mailarchive.ietf.org/arch/msg/rats/gQ6ISRSUywuFgIAqVl-MToStVHo/ |
2024-05-23
|
26 | (System) | Changed action holders to Roman Danyliw, Laurence Lundblade, Giridhar Mandyam, Jeremy O'Donoghue, Carl Wallace (IESG state changed) |
2024-05-23
|
26 | Roman Danyliw | IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested |
2024-05-19
|
26 | Roman Danyliw | Last call announcement was generated |
2024-05-17
|
26 | Ned Smith | # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the … # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the responsibilities is answering the questions in this write-up to give helpful context to Last Call and Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in completing it is appreciated. The full role of the shepherd is further described in [RFC 4858][2]. You will need the cooperation of the authors and editors to complete these checks. Note that some numbered items contain multiple related questions; please be sure to answer all of them. ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? While there was strong contribution of small group, there was broad consensus to move with the current version of the draft. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? Intial versions of the draft were too broad in scope, the resulting draft is the content That reached broad consensus 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? Known or planned implementations of EAT or a profile of EAT: EAT Libraries: - CBOR Formats - open source project o Rust: https://github.com/carl-wallace/cbor_formats - EAT library - open source project o C: https://github.com/laurencelundblade/ctoken - A command line utility based on EAT library - open source project o C: https://github.com/laurencelundblade/xclaim EAT Profiles: - PSA o Golang: https://github.com/veraison/psatoken o C: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/partitions/initial_attestation o Python: https://git.trustedfirmware.org/TF-M/tf-m-tools.git/tree/iat-verifier - CCA o Golang: https://github.com/veraison/ccatoken o C: https://git.trustedfirmware.org/TF-RMM/tf-rmm.git/tree/lib/attestation - FIDO FDO - open source project o Java: https://github.com/secure-device-onboard/pri-fidoiot/blob/master/protocol/src/main/java/org/fidoalliance/fdo/protocol/message/EatPayloadBase.java. - Global Platform - very early code of an EAT profile, may evolve into open source o https://github.com/GlobalPlatform/TPS-API-Reference-Implementations. - Microsoft Azure Attestation - proprietary o https://github.com/CCC-Attestation/meetings/blob/main/materials/GregKostal_EAT_in_MAA.pdf ## Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. Yes, there is close relation to other drafts in RATS (e.g., UCCS and the RATS Architecture), more importantly it leverages the work from (ACE/JOSE/COSE) as it uses JWT and CWTs and generates extensions to those groups. There is also alignment with the FIDO Alliance organization as they look to leverage the claims defined in this draft. 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The draft has acquired early IANA assignment as well as expert review on the Oauth/JWT and CWT. See answer to #21. 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? No, YANG is not used or specified in this draft. 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. We cloned and built the EAT github repository locally which is based on the Thomson template (martinthomson/i-d-template: A template for IETF internet draft git repositories (github.com)) and it built without errors, but with one warning that identified a unused informative reference. There was one informative reference to a draft that has since become an RFC that should be updated. The eat draft relies on CDDL for normative statements. The CDDL is verified correct using a make file that checks the CDDL against examples. The same CDDL files are imported into the draft giving high confidence they are syntactically correct. ## Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? I have reviewed the document and believe it is ready for Area Directory review. The EAT I-D is a set of claims that are intended for use within a CWT or JWT web token. There aren’t any mandatory to use claims as their use is prescribed according to a profile that may be user, application, or vendor specific. The intent of the draft is to define claim syntax and semantics such that if a claim is asserted by one entity, a receiving entity will be able to process the claim by reading the EAT draft. The RATS Architecture RFC 9334: Remote ATtestation procedureS (RATS) Architecture (ietf.org) defines several attestation conceptual messages. Claims contained in the EAT draft could be used by some or all the conceptual messages. There may be claims defined in EAT that are better suited to one type of conceptual message over another, but it was not a goal of the draft to stereo type the claims to conceptual messages. There were several discussions on the email list and in face-to-face meetings to clarify these objectives. Some of the proposed claims were less well defined or thought to be unnecessary and were removed from the final draft. Other claims were thought to be highly useful, such that the working group sought and obtained early allocation from IANA registries. The FIDO Alliance has incorporated some of the early allocation claims into at least one of their specifications. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? This draft received reviews from SECDir and IoTdir representatives. One issue raised was an interoperability concern. If a profile is required to direct which claims are used and, in some cases, how they are to be applied, wouldn’t that suggest that the profile is point at which interoperability is guaranteed. The working group resolved this issue by observing that all web tokens require similar qualification. As a building block specification, it is anticipated that other standards groups will write specifications that define meaningful profiles, but it is also possible that vendor-specific profiles could be defined as well. There is a public vendor specific profile here: draft-tschofenig-rats-psa-token-10 - Arm's Platform Security Architecture (PSA) Attestation Token (ietf.org). Another concern raised had to do with the way certain claims were described, and whether the description was semantically clear and sufficient to avoid downstream security issues. The authors addressed these concerns by rewriting the section or by removing the claim altogether (possibly to be reintroduced in a future draft). Some of the feedback observed that EAT refers to attestation ‘protocols’ where that may be too specific as the RATS Architecture refers to them as ‘conveyance’ mechanisms. The EAT draft does not intend to define a protocol per se but does anticipate being used to define a conceptual message type that is included as a payload in a protocol that supports attestation. Still other review feedback included concerns about possible semantic differences that could occur given different conceptual message contexts. A claim asserted as Evidence could have different meaning if asserted as Attestation Results, for example. The working group resolved these concerns by revising EAT normative that seemed to prescribe a meaning assuming a particular conceptual message type but didn’t clearly articulate the assumption as part of the description. 11. What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? Request is for “Proposed Standard”, the datatracker and draft reflect the intent. 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][7]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. Yes, we did a query to the RATs mail list as well as a unicast request to the draft authors and no IPR disclosures were submitted or known to the participants. 13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. Yes. 14. Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) The EAT draft appears to follow the I-D style guidelines and uses the convention that “this document” should be replaced with “this RFC” when an RFC status is granted. It makes use of acronyms by defining the expanded name and including a parenthetical abbreviation. The draft appears to make proper use of RFC2119 for normative statements. The draft appears to follow guidelines in NISTIR8366. There doesn’t appear to be stale text. 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. The RATS chairs identified two informative references [IEEE.802-2001] and [OUI.Guide] that possibly should be normative. The chairs notified the authors to determine if this is appropriate. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? All normative references are freely available. 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them. There are 4 normative references to non-standards track RFCs: RFC2119, RFC8126, RFC8174, RFC8792 and two references to I-Ds: https://datatracker.ietf.org/doc/html/draft-ietf-suit-manifest-21 and https://datatracker.ietf.org/doc/html/draft-ietf-sacm-coswid-22. 18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? The two cited I-Ds are progressing toward RFC status. This I-D should update these references when they become RFCs. RFC9052 and RFC8949 make normative reference to RFC2119 and RFC8174. Possibly, these should be added to the downref exceptions registry Downref registry (ietf.org)? The I-D authors believe RFC8126 and RFC8792 do not need to be normative references. They plan to make this change in v20 of the EAT draft. 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. No 20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]). The IANA considerations section identifies the code points that have been previously assigned based on a pre-allocation request and the remaining code points are clearly described as requiring IANA allocation. 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. There are several IANA registries that are impacted by this I-D. Michael Jones would be the appropriate designated expert. The set of IANA registries affected are copied from the EAT draft as follows: 10.2. CWT and JWT Claims Registered by This Document This specification adds the following values to the "JSON Web Token Claims" registry established by [RFC7519] and the "CBOR Web Token Claims Registry" established by [RFC8392]. Each entry below is an addition to both registries.¶ The "Claim Description", "Change Controller" and "Specification Documents" are common and equivalent for the JWT and CWT registries. The "Claim Key" and "Claim Value Types(s)" are for the CWT registry only. The "Claim Name" is as defined for the CWT registry, not the JWT registry. The "JWT Claim Name" is equivalent to the "Claim Name" in the JWT registry. IANA is requested to register the following claims. RFC Editor: Please make the following adjustments and remove this paragraph. Replace "this document" with this RFC number. In the following, the claims with "Claim Key: TBD" need to be assigned a value in the Specification Required Range, preferrably starting around 267. Those below already with a Claim Key number were given early assignment. No change is requested for them except for Claim Key 262. Claim 262 should be renamed from "secboot" to "oemboot" in the JWT registry and it's description changed in both the CWT and JWT registries. • Claim Name: Nonce¶ • Claim Description: Nonce¶ • JWT Claim Name: "eat_nonce"¶ • Claim Key: 10¶ • Claim Value Type(s): byte string¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: UEID¶ • Claim Description: The Universal Entity ID¶ • JWT Claim Name: "ueid"¶ • CWT Claim Key: 256¶ • Claim Value Type(s): byte string¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: SUEIDs¶ • Claim Description: Semi-permanent UEIDs¶ • JWT Claim Name: "sueids"¶ • CWT Claim Key: 257¶ • Claim Value Type(s): map¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Hardware OEMID¶ • Claim Description: Hardware OEM ID¶ • JWT Claim Name: "oemid"¶ • Claim Key: 258¶ • Claim Value Type(s): byte string or integer¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Hardware Model¶ • Claim Description: Model identifier for hardware¶ • JWT Claim Name: "hwmodel"¶ • Claim Key: 259¶ • Claim Value Type(s): byte string¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Hardware Version¶ • Claim Description: Hardware Version Identifier¶ • JWT Claim Name: "hwversion"¶ • Claim Key: TBD 260¶ • Claim Value Type(s): array¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: OEM Authortised Boot¶ • Claim Description: Indicate whether the software booted was OEM authorized¶ • JWT Claim Name: "oemboot"¶ • Claim Key: 262¶ • Claim Value Type(s): Boolean¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Debug Status¶ • Claim Description: Indicate status of debug facilities¶ • JWT Claim Name: "dbgstat"¶ • Claim Key: 263¶ • Claim Value Type(s): integer or string¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Location¶ • Claim Description: The geographic location¶ • JWT Claim Name: "location"¶ • Claim Key: 264¶ • Claim Value Type(s): map¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: EAT Profile¶ • Claim Description: Indicates the EAT profile followed¶ • JWT Claim Name: "eat_profile"¶ • Claim Key: 265¶ • Claim Value Type(s): URI or OID¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Submodules Section¶ • Claim Description: The section containing submodules¶ • JWT Claim Name: "submods"¶ • Claim Key: 266¶ • Claim Value Type(s): map¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Uptime¶ • Claim Description: Uptime¶ • JWT Claim Name: "uptime"¶ • Claim Key: TBD¶ • Claim Value Type(s): unsigned integer¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Boot Count¶ • Claim Description: The number times the entity or submodule has been booted¶ • JWT Claim Name: "bootcount"¶ • Claim Key: TBD¶ • Claim Value Type(s): uint¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Boot Seed¶ • Claim Description: Identifies a boot cycle¶ • JWT Claim Name: "bootseed"¶ • Claim Key: TBD¶ • Claim Value Type(s): bytes¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: DLOAs¶ • Claim Description: Certifications received as Digital Letters of Approval¶ • JWT Claim Name: "dloas"¶ • Claim Key: TBD¶ • Claim Value Type(s): array¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Software Name¶ • Claim Description: The name of the software running in the entity¶ • JWT Claim Name: "swname"¶ • Claim Key: TBD¶ • Claim Value Type(s): map¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Software Version¶ • Claim Description: The version of software running in the entity¶ • JWT Claim Name: "swversion"¶ • Claim Key: TBD¶ • Claim Value Type(s): map¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Software Manifests¶ • Claim Description: Manifests describing the software installed on the entity¶ • JWT Claim Name: "manifests"¶ • Claim Key: TBD¶ • Claim Value Type(s): array¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Measurements¶ • Claim Description: Measurements of the software, memory configuration and such on the entity¶ • JWT Claim Name: "measurements"¶ • Claim Key: TBD¶ • Claim Value Type(s): array¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Software Measurement Results¶ • Claim Description: The results of comparing software measurements to reference values¶ • JWT Claim Name: "measres"¶ • Claim Key: TBD¶ • Claim Value Type(s): array¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Intended Use¶ • Claim Description: Indicates intended use of the EAT¶ • JWT Claim Name: "intuse"¶ • Claim Key: TBD¶ • Claim Value Type(s): integer or string¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ 10.3. UEID URN Registered by this Document IANA is requested to register the following new subtypes in the "DEV URN Subtypes" registry under "Device Identification". See [RFC9039].¶ Table 3 Subtype Description Reference ueid Universal Entity Identifier This document sueid Semi-permanent Universal Entity Identifier This document 10.4. CBOR Tag for Detached EAT Bundle Registered by this Document In the registry [IANA.cbor-tags], IANA is requested to allocate the following tag from the FCFS space, with the present document as the specification reference.¶ Table 4 Tag Data Items Semantics TBD602 array Detached EAT Bundle Section 5 10.5. Media Types Registered by this Document It is requested that the CoAP Content-Format for SPDX and CycloneDX be been registered in the "CoAP Content-Formats" subregistry within the "Constrained RESTful Environments (CoRE) Parameters" registry [IANA.core-parameters]:¶ • Media Type: application/spdx+json¶ • Encoding: binary¶ • ID: TBD¶ • Reference: [SPDX]¶ • Media Type: vendor/vnd.cyclonedx+xml¶ • Encoding: binary¶ • ID: TBD¶ • Reference: [CycloneDX]¶ • Media Type: vendor/vnd.cyclonedx+json¶ • Encoding: binary¶ • ID: TBD¶ • Reference: [CycloneDX] [1]: https://www.ietf.org/about/groups/iesg/ [2]: https://www.rfc-editor.org/rfc/rfc4858.html [3]: https://www.rfc-editor.org/rfc/rfc7942.html [4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp79 [8]: https://www.ietf.org/tools/idnits/ [9]: https://www.rfc-editor.org/rfc/rfc3967.html [10]: https://www.rfc-editor.org/info/bcp97 [11]: https://www.rfc-editor.org/rfc/rfc8126.html [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]: https://authors.ietf.org/en/content-guidelines-overview [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ [17]: https://datatracker.ietf.org/doc/downref/ |
2024-05-17
|
26 | Ned Smith | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2024-05-17
|
26 | Ned Smith | IESG state changed to Publication Requested from I-D Exists |
2024-05-17
|
26 | Ned Smith | Document is now in IESG state Publication Requested |
2024-05-10
|
26 | (System) | Changed action holders to Roman Danyliw (IESG state changed) |
2024-05-10
|
26 | Roman Danyliw | IESG state changed to I-D Exists from RFC Ed Queue |
2024-05-07
|
26 | Kathleen Moriarty | Document already up-to-date |
2024-05-07
|
26 | Kathleen Moriarty | Tag Revised I-D Needed - Issue raised by WG cleared. |
2024-05-07
|
26 | Kathleen Moriarty | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2024-05-06
|
26 | Kathleen Moriarty | The Working Group elected to move the document back to the WG state in order to remove a reliance on 2 documents. |
2024-05-06
|
26 | Kathleen Moriarty | Tag Revised I-D Needed - Issue raised by WG set. |
2024-05-06
|
26 | Kathleen Moriarty | IETF WG state changed to WG Document from Submitted to IESG for Publication |
2024-05-06
|
26 | (System) | RFC Editor state changed to EDIT from MISSREF |
2024-05-05
|
26 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-26.txt |
2024-05-05
|
26 | (System) | New version approved |
2024-05-05
|
26 | (System) | Request for posting confirmation emailed to previous authors: Carl Wallace , Giridhar Mandyam , Jeremy O'Donoghue , Laurence Lundblade |
2024-05-05
|
26 | Giridhar Mandyam | Uploaded new revision |
2024-01-16
|
25 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2024-01-15
|
25 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-25.txt |
2024-01-15
|
25 | (System) | New version approved |
2024-01-15
|
25 | (System) | Request for posting confirmation emailed to previous authors: Carl Wallace , Giridhar Mandyam , Jeremy O'Donoghue , Laurence Lundblade |
2024-01-15
|
25 | Giridhar Mandyam | Uploaded new revision |
2024-01-12
|
24 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2024-01-12
|
24 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2024-01-12
|
24 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2024-01-12
|
24 | (System) | IANA Action state changed to In Progress from On Hold |
2024-01-05
|
24 | (System) | IANA Action state changed to On Hold from In Progress |
2024-01-05
|
24 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2023-12-21
|
24 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2023-12-20
|
24 | (System) | RFC Editor state changed to MISSREF |
2023-12-20
|
24 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2023-12-20
|
24 | (System) | Announcement was received by RFC Editor |
2023-12-19
|
24 | (System) | IANA Action state changed to In Progress |
2023-12-19
|
24 | (System) | Removed all action holders (IESG state changed) |
2023-12-19
|
24 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2023-12-19
|
24 | Cindy Morgan | IESG has approved the document |
2023-12-19
|
24 | Cindy Morgan | Closed "Approve" ballot |
2023-12-19
|
24 | Cindy Morgan | Ballot approval text was generated |
2023-12-18
|
24 | Roman Danyliw | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2023-12-16
|
24 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-24.txt |
2023-12-16
|
24 | (System) | New version approved |
2023-12-16
|
24 | (System) | Request for posting confirmation emailed to previous authors: Carl Wallace , Giridhar Mandyam , Jeremy O'Donoghue , Laurence Lundblade |
2023-12-16
|
24 | Giridhar Mandyam | Uploaded new revision |
2023-12-14
|
23 | (System) | Changed action holders to Roman Danyliw (IESG state changed) |
2023-12-14
|
23 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2023-12-14
|
23 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-23.txt |
2023-12-14
|
23 | (System) | New version approved |
2023-12-14
|
23 | (System) | Request for posting confirmation emailed to previous authors: Carl Wallace , Giridhar Mandyam , Jeremy O'Donoghue , Laurence Lundblade , rats-chairs@ietf.org |
2023-12-14
|
23 | Giridhar Mandyam | Uploaded new revision |
2023-12-08
|
22 | Roman Danyliw | Pending merges: https://github.com/ietf-rats-wg/eat/pull/432; https://github.com/ietf-rats-wg/eat/pull/431. Discussion on https://github.com/ietf-rats-wg/eat/pull/430. |
2023-12-08
|
22 | (System) | Changed action holders to Laurence Lundblade, Giridhar Mandyam, Jeremy O'Donoghue, Carl Wallace (IESG state changed) |
2023-12-08
|
22 | Roman Danyliw | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::AD Followup |
2023-10-25
|
22 | Barry Leiba | Closed request for Last Call review by ARTART with state 'Overtaken by Events': Document has finished IESG processing |
2023-10-25
|
22 | Barry Leiba | Assignment of request for Last Call review by ARTART to Jaime Jimenez was marked no-response |
2023-10-24
|
22 | (System) | Removed all action holders (IESG state changed) |
2023-10-24
|
22 | Roman Danyliw | IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation::AD Followup |
2023-10-17
|
22 | Murray Kucherawy | [Ballot comment] Section 10.2 contains some 20 registrations for claim names, but they all run together at least in the basic HTML representation. Could we … [Ballot comment] Section 10.2 contains some 20 registrations for claim names, but they all run together at least in the basic HTML representation. Could we put them into subsections, or separate them out in some other way? Regarding Appendix B.2, it might be worthwhile to check out the revision go RFC4122 that's in progress in the UUIDREV working group, if you haven't already done that, just to make sure the prose here isn't about to become obsolete. |
2023-10-17
|
22 | Murray Kucherawy | [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from Discuss |
2023-10-14
|
22 | (System) | Changed action holders to Roman Danyliw (IESG state changed) |
2023-10-14
|
22 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2023-10-14
|
22 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2023-10-14
|
22 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-22.txt |
2023-10-14
|
22 | (System) | New version approved |
2023-10-14
|
22 | (System) | Request for posting confirmation emailed to previous authors: Carl Wallace , Giridhar Mandyam , Jeremy O'Donoghue , Laurence Lundblade |
2023-10-14
|
22 | Giridhar Mandyam | Uploaded new revision |
2023-09-08
|
21 | Robert Wilton | [Ballot comment] Discuss cleared based on the agreement to make the change proposed below. (2) p 0, sec An EAT is either a CBOR … [Ballot comment] Discuss cleared based on the agreement to make the change proposed below. (2) p 0, sec An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims. This is probably contentious, but given that this is a new spec, I wonder whether it wouldn't be better (i.e., encourage wider interop) if only CBOR, COSE and CWT were used/allowed. (3) p 20, sec 4.2.6. swname (Software Name) Claim The "swname" claim contains a very simple free-form text value for naming the software used by the entity. Intentionally, no general rules or structure are set. This will make it unsuitable for use cases that wish precise naming. I found it interesting, and slightly surprising, that the hardware model claim is opaque, but the software name claim is not. (4) p 24, sec 4.2.11. uptime (Uptime) Claim The "uptime" claim MUST contain a value that represents the number of seconds that have elapsed since the entity or submodule was last booted. Relative to other claim descriptions, the MUST in this description seems strange. Perhaps better as just "The "uptime" claim contains a value ..." (5) p 88, sec Appendix B. UEID Design Rationale A UEID is not a UUID [RFC4122] by conscious choice for the following reasons. Note that the UUID spec is currently being updated (it is also on this week's telechat review), so some of the concerns being described here may no longer be valid. It is still only 128 bits though, and 6 bits are spent identifying UUID format and version. (6) p 89, sec Appendix B. UEID Design Rationale Note also that that a type 2 UEID (EUI/MAC) is only 7 bytes compared to 16 for a UUID. Note that the paragraph at the end of appendix B.1. states that UEIDs are a minumum of 128 bits ... Regards, Rob |
2023-09-08
|
21 | Robert Wilton | [Ballot Position Update] Position for Robert Wilton has been changed to No Objection from Discuss |
2023-09-07
|
21 | (System) | Changed action holders to Laurence Lundblade, Giridhar Mandyam, Jeremy O'Donoghue, Carl Wallace, Roman Danyliw (IESG state changed) |
2023-09-07
|
21 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2023-09-07
|
21 | Warren Kumari | [Ballot comment] [ Thank you for addressing my DISCUSS comment regarding company lifetime. ] I mostly have a few comments: 1: It would have been … [Ballot comment] [ Thank you for addressing my DISCUSS comment regarding company lifetime. ] I mostly have a few comments: 1: It would have been really nice to have an example at the beginning of the document to help make this less abstract for the reader. Yes, there are examples further into the document, and a reader unfamiliar with the technology can always go look at one of those, but having a (very simple) example near the top of the document would help greatly... 2: S 4.2.1.1. Rules for Creating UEIDs For the IEEE EUI you say: "This uses the IEEE company identification registry.", but for 0x03 IMEI all you say is "This is a 14-digit identifier consisting of an 8-digit Type Allocation Code and a 6-digit serial number allocated by the manufacturer". This doesn't say who actually assigns the TAC -- I believe that it is GSMA. 3: S 4.2.3.1. Random Number Based OEMID "The OEM MAY create their own ID by using a cryptographic-quality random number generator." -- the use of uppercase MAY feels weird here, and I suggest that you s/MAY/may. 4: Nit. "Certain EAT claims can be used to track the owner of an entity and therefore, implementations should consider providing privacy-preserving options dependent on the intended usage of the EAT." The grammar here seems odd -- I'd suggest: "Certain EAT claims can be used to track the owner of an entity; therefore, implementations should consider providing privacy-preserving options dependent on the intended usage of the EAT." |
2023-09-07
|
21 | Warren Kumari | [Ballot Position Update] Position for Warren Kumari has been changed to No Objection from Discuss |
2023-09-07
|
21 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2023-09-07
|
21 | Éric Vyncke | [Ballot comment] # Éric Vyncke, INT AD, comments for draft-ietf-rats-eat-21 [Please accept all my apologies for such a superficial review, e.g., I skipped all the … [Ballot comment] # Éric Vyncke, INT AD, comments for draft-ietf-rats-eat-21 [Please accept all my apologies for such a superficial review, e.g., I skipped all the encoding part, lack of time :( ] Thank you for the work put into this document. ***To be honest, I was about to raise a DISCUSS level issue on this appendix A, but as it is 'just' an appendix, I only raised a COMMENT see below. Similar level for appendix B.2 comment*** Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Ned Smith for the shepherd's *very* detailed write-up including the WG consensus and the discussion about directorates reviews (including iot-dir by Eliot Lear [1]) and the justification of the intended status. Other thanks to Haoyu Song, the Internet directorate reviewer, please consider this int-dir review: https://datatracker.ietf.org/doc/review-ietf-rats-eat-21-intdir-telechat-song-2023-09-05/ (and I have read author's and sheperd's replies, thanks) I hope that this review helps to improve the document, Regards, -éric [1] https://datatracker.ietf.org/doc/review-ietf-rats-eat-13-iotdir-lc-lear-2022-06-05/ # COMMENTS ## Section 4.2.1 `UEIDs MUST be universally and globally unique across manufacturers and countries` please add some text like "as described in next section" ## Section 4.2.1.1 What is the "consumer" in `The consumer need not have any awareness of them`. Should this term be listed in the terminology section ? For the "IEEE EUI", should there be some text about virtual machines also having dynamic (not unique) MAC addresses ? ## Section 4.2.9 `It applies to any software debug facilities related to root, operating system or privileged software`, as my review is rather quick, I may have missed the definition of "root" in the context of this document. Is it defined somewhere ? ## Section 4.2.10 Please note that "GPS" is a commercial name of a USA-based navigation system (there is also Galileo or Glonass). Please use the inclusive and more accurate term of GNSS (Global Navigation Satellite System). ## Appendix A `WARNING: These examples use tag and label numbers not yet assigned by IANA.` *Strongly* suggest to add a note to the RFC editor to request the authors to redo the examples. ## Appendix A.1.4 Should an informative reference be added to `This is similar to Android Key Attestation` ? ## Appendix B.1 Simple word: WoW ! (eye opening) ## Appendix B.2 I find sad that the reference to UUID is the existing RFC 4122 while, at this very same IESG telechat, there is draft-ietf-uuidrev-rfc4122bis-11... STRONGLY suggest to use draft-ietf-uuidrev-rfc4122bis-11 as the reference *IF* applicable. ## Appendix C Was there any liaison with IEEE on this section ? ## Appendix E Should this section be part of the normative text ? # NITS ## Section 1 Even if "TPM" is assumed to be well-known per RFC editor, may I suggest to expand on first use ? Even more for "TEE" later in section 1.1 |
2023-09-07
|
21 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2023-09-07
|
21 | Robert Wilton | [Ballot discuss] Hi, Thanks for this document. Sorry, I didn't have time to review this document that closely. I have flagged one issue for discussion … [Ballot discuss] Hi, Thanks for this document. Sorry, I didn't have time to review this document that closely. I have flagged one issue for discussion to change the reference to the architecture document to being a normative reference. This would mean a downref, but should otherwise be an easy change to make. The rest of my comments are non-blocking. (1) p 71, sec 11.2. Informative References [RATS.Architecture] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", Work in Progress, Internet-Draft, draft- ietf-rats-architecture-22, 28 September 2022, . "From section 1.3, EAT follows the operational model described in Figure 1 in [RATS.Architecture].". This, along with other references indicates that the RATS architecture should be a normative reference. |
2023-09-07
|
21 | Robert Wilton | [Ballot comment] (2) p 0, sec An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims. … [Ballot comment] (2) p 0, sec An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims. This is probably contentious, but given that this is a new spec, I wonder whether it wouldn't be better (i.e., encourage wider interop) if only CBOR, COSE and CWT were used/allowed. (3) p 20, sec 4.2.6. swname (Software Name) Claim The "swname" claim contains a very simple free-form text value for naming the software used by the entity. Intentionally, no general rules or structure are set. This will make it unsuitable for use cases that wish precise naming. I found it interesting, and slightly surprising, that the hardware model claim is opaque, but the software name claim is not. (4) p 24, sec 4.2.11. uptime (Uptime) Claim The "uptime" claim MUST contain a value that represents the number of seconds that have elapsed since the entity or submodule was last booted. Relative to other claim descriptions, the MUST in this description seems strange. Perhaps better as just "The "uptime" claim contains a value ..." (5) p 88, sec Appendix B. UEID Design Rationale A UEID is not a UUID [RFC4122] by conscious choice for the following reasons. Note that the UUID spec is currently being updated (it is also on this week's telechat review), so some of the concerns being described here may no longer be valid. It is still only 128 bits though, and 6 bits are spent identifying UUID format and version. (6) p 89, sec Appendix B. UEID Design Rationale Note also that that a type 2 UEID (EUI/MAC) is only 7 bytes compared to 16 for a UUID. Note that the paragraph at the end of appendix B.1. states that UEIDs are a minumum of 128 bits ... Regards, Rob |
2023-09-07
|
21 | Robert Wilton | [Ballot Position Update] New position, Discuss, has been recorded for Robert Wilton |
2023-09-07
|
21 | Jim Guichard | [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard |
2023-09-07
|
21 | Murray Kucherawy | [Ballot discuss] The way Section 4.2.8 defines "oemboot" appears to require "oemid" in order to fully understand what's being claimed. So why is the presence … [Ballot discuss] The way Section 4.2.8 defines "oemboot" appears to require "oemid" in order to fully understand what's being claimed. So why is the presence of "oemid" only a SHOULD? |
2023-09-07
|
21 | Murray Kucherawy | [Ballot comment] Why the SHOULD in 4.2.15? What happens if I don't? Does it matter? Section 10.2 contains some 20 registrations for claim names, but … [Ballot comment] Why the SHOULD in 4.2.15? What happens if I don't? Does it matter? Section 10.2 contains some 20 registrations for claim names, but they all run together at least in the basic HTML representation. Could we put them into subsections, or separate them out in some other way? Regarding Appendix B.2, it might be worthwhile to check out the revision go RFC4122 that's in progress in the UUIDREV working group, if you haven't already done that, just to make sure the prose here isn't about to become obsolete. |
2023-09-07
|
21 | Murray Kucherawy | [Ballot Position Update] New position, Discuss, has been recorded for Murray Kucherawy |
2023-09-06
|
21 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2023-09-06
|
21 | Warren Kumari | [Ballot discuss] Be ye not afraid -- a DISCUSS ballot is a request to have a discussion -- https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ . 4: S 4.2.3.1. Random Number … [Ballot discuss] Be ye not afraid -- a DISCUSS ballot is a request to have a discussion -- https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ . 4: S 4.2.3.1. Random Number Based OEMID "They would perform this only once in the life of the company to generate the single ID for said company. They would use that same ID in every entity they make. This uniquely identifies the OEM on a statistical basis and is large enough should there be ten billion companies." It is very unclear what exactly the "life of a company" is here. America Online has been, variously: Control Video Corporation (1983–1985) Quantum Computer Services (1985–1991) America Online (1991–2009) AOL Time Warner (2001–2009) AOL (2009 - 2015) AOL, part of Verizon (2015 - now) At what point(s) in this tangled web (if ever) should "AOL" have generated a new "single SID"? Another example: "In April 2012, Facebook paid $1B for Instagram, a photo and video sharing software." -- which "single" SID should Facebook (whoops, Meta) used for Oculus headsets? |
2023-09-06
|
21 | Warren Kumari | [Ballot comment] I mostly have a few comments: 1: It would have been really nice to have an example at the beginning of the document … [Ballot comment] I mostly have a few comments: 1: It would have been really nice to have an example at the beginning of the document to help make this less abstract for the reader. Yes, there are examples further into the document, and a reader unfamiliar with the technology can always go look at one of those, but having a (very simple) example near the top of the document would help greatly... 2: S 4.2.1.1. Rules for Creating UEIDs For the IEEE EUI you say: "This uses the IEEE company identification registry.", but for 0x03 IMEI all you say is "This is a 14-digit identifier consisting of an 8-digit Type Allocation Code and a 6-digit serial number allocated by the manufacturer". This doesn't say who actually assigns the TAC -- I believe that it is GSMA. 3: S 4.2.3.1. Random Number Based OEMID "The OEM MAY create their own ID by using a cryptographic-quality random number generator." -- the use of uppercase MAY feels weird here, and I suggest that you s/MAY/may. 4: Nit. "Certain EAT claims can be used to track the owner of an entity and therefore, implementations should consider providing privacy-preserving options dependent on the intended usage of the EAT." The grammar here seems odd -- I'd suggest: "Certain EAT claims can be used to track the owner of an entity; therefore, implementations should consider providing privacy-preserving options dependent on the intended usage of the EAT." |
2023-09-06
|
21 | Warren Kumari | [Ballot Position Update] New position, Discuss, has been recorded for Warren Kumari |
2023-09-06
|
21 | John Scudder | [Ballot comment] Please gloss TEE or expand on first use. Thanks. |
2023-09-06
|
21 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2023-09-06
|
21 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2023-09-06
|
21 | Amanda Baber | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
2023-09-06
|
21 | David Dong | Experts have approved the JSON Web Token Claims, the CBOR Web Token (CWT) Claims, and the DEV URN Subtypes registrations. Comments from one of the … Experts have approved the JSON Web Token Claims, the CBOR Web Token (CWT) Claims, and the DEV URN Subtypes registrations. Comments from one of the experts for the CBOR Web Token (CWT) Claims registrations: I approve of these CWT Claim registrations. I suggest these CWT claim number assignments: Uptime - 261 Boot Count - 267 Boot Seed - 268 DLOAs - 269 Software Name - 270 Software Version - 271 Software Manifests - 272 Measurements - 273 Software Measurement Results - 274 Intended Use - 275 -- Mike Comments from one of the experts for the DEV URN Subtypes registrations: I have reviewed the allocation of a DEV URN subtype for this use. This is in general fine, and I’m happy you’re doing this. So your allocation is OK from my perspective. However, there seems to be some details missing (or I simply missed them 😊 ). You should define the syntax of your new DEV URN subtypes. For instance, in RFC 9039 the mac address subtypes have been defined with the ABNF: macbody = %s"mac:" hex-string I’m missing a similar definition in this document. Or is it the intention that parts of the syntax you define for claims, e.g.. ueid-type are the syntax also for the DEV URNs? But if so, you should explicitly say this. (And would ueid-type conform to the general syntax of DEV URNs? Not sure I understand how they are actually encoded, are these binary or textual strings?) An example would also be nice. Perhaps you could simply define the syntax using ABNF, e.g., body =/ ueidbody ueidbody = %s”ueid:” base64string Some nits on the rest of the document: 4.2.1. ueid (Universal Entity ID) Claim … UEIDs are not designed for direct use by humans (e.g., printing on the case of a device), so no textual representation is defined. There are privacy considerations for UEIDs. See Section 8.1. A Device Identifier URN is registered for UEIDs. See Section 10.3. $$Claims-Set-Claims //= (ueid-label => ueid-type) ueid-type = JC It seems to me that atleast DEV URNs and perhaps also your ueid-type actually are textual representations, even if perhaps not meant to typed by users. Wondering if you want to adjust your text about no textual representation? Same question for Section 4.2.2 and sueids. Jari |
2023-09-06
|
21 | Zaheduzzaman Sarker | [Ballot comment] Thanks for working on this document. I have no issues from TSV point of view. |
2023-09-06
|
21 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2023-09-05
|
21 | Haoyu Song | Request for Telechat review by INTDIR Completed: Ready with Issues. Reviewer: Haoyu Song. Sent review to list. |
2023-08-31
|
21 | Juan-Carlos Zúñiga | Request for Telechat review by INTDIR is assigned to Haoyu Song |
2023-08-25
|
21 | Roman Danyliw | Placed on agenda for telechat - 2023-09-07 |
2023-08-25
|
21 | Roman Danyliw | Ballot has been issued |
2023-08-25
|
21 | Roman Danyliw | [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw |
2023-08-25
|
21 | Roman Danyliw | Created "Approve" ballot |
2023-08-25
|
21 | Roman Danyliw | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2023-08-25
|
21 | Roman Danyliw | Ballot writeup was changed |
2023-08-16
|
21 | David Dong | Experts have approved the JSON Web Token Claims and CBOR Web Token (CWT) Claims registrations. Comments from one of the experts for the CBOR Web … Experts have approved the JSON Web Token Claims and CBOR Web Token (CWT) Claims registrations. Comments from one of the experts for the CBOR Web Token (CWT) Claims registrations: I approve of these CWT Claim registrations. I suggest these CWT claim number assignments: Uptime - 261 Boot Count - 267 Boot Seed - 268 DLOAs - 269 Software Name - 270 Software Version - 271 Software Manifests - 272 Measurements - 273 Software Measurement Results - 274 Intended Use - 275 -- Mike |
2023-08-16
|
21 | David Dong | IANA Experts State changed to Reviews assigned |
2023-08-09
|
21 | Ines Robles | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Ines Robles. Sent review to list. |
2023-08-09
|
21 | Linda Dunbar | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Linda Dunbar. Sent review to list. |
2023-08-09
|
21 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2023-08-08
|
21 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2023-08-08
|
21 | David Dong | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-rats-eat-21. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-rats-eat-21. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has questions about each of the first six actions requested in the IANA Considerations section of this document. The IANA Functions Operator understands that, upon approval of this document, there are eight actions which we must complete. First, in the JSON Web Token Claims registry in the JSON Web Token (JWT) registry group located at: https://www.iana.org/assignments/jwt/ The following ten temporary registrations will be made permanent and their references changed to [ RFC-to-be ]. ueid The Universal Entity ID sueids Semi-permanent UEIDs oemid Hardware OEM ID hwmodel Model identifier for hardware hwversion Hardware Version Identifier secboot Indicate whether the boot was secure dbgstat Indicate status of debug facilities location The geographic location eat_profile Indicates the EAT profile followed submods The section containing submodules IANA QUESTION -> Should the description for dbgstat be changed to "Indicates status of debug facilities"? Second, in the CBOR Web Token (CWT) Claims registry located at: https://www.iana.org/assignments/cwt/ The following eleven temporary registrations will be made permanent and their references changed to [ RFC-to-be ]. Nonce Nonce UEID The Universal Entity ID SUEIDs Semi-permanent UEIDs Hardware OEMID Hardware OEM ID Hardware Model Model identifier for hardware Hardware Version Hardware Version Identifier Secure Boot Indicate whether the boot was secure Debug Status Indicate status of debug facilities Location The geographic location Profile Indicates the EAT profile followed Submodules Section The section containing submodules IANA QUESTION -> Should the description for Debug Status be changed to "Indicates status of debug facilities"? Third, in the JSON Web Token Claims registry in the JSON Web Token (JWT) registry group located at: https://www.iana.org/assignments/jwt/ ten new Web Token registrations will be made as follows: IANA QUESTION -> Would it be acceptable to list the IETF as the change controller for the JSON Web Token Claims and CBOR Web Token (CWT) Claims registrations instead of the IESG? There has been a preference for doing so, as described in the expired document at https://datatracker.ietf.org/doc/html/draft-leiba-ietf-iana-registrations-00, but it has not been recorded in a permanent document yet. Claim Name: uptime Claim Description: Uptime Change Controller: IETF Reference: [ RFC-to-be ] Claim Name: bootcount Claim Description: The number times the entity or submodule has been booted Change Controller: IETF Reference: [ RFC-to-be ] Claim Name: bootseed Claim Description: Identifies a boot cycle Change Controller: IETF Reference: [ RFC-to-be ] Claim Name: dloas Claim Description: Certifications received as Digital Letters of Approval Change Controller: IETF Reference: [ RFC-to-be ] Claim Name: swname Claim Description: The name of the software running in the entity Change Controller: IETF Reference: [ RFC-to-be ] Claim Name: swversion Claim Description: The version of software running in the entity Change Controller: IETF Reference: [ RFC-to-be ] Claim Name: manifests Claim Description: Manifests describing the software installed on the entity Change Controller: IETF Reference: [ RFC-to-be ] Claim Name: measurements Claim Description: Measurements of the software, memory configuration and such on the entity Change Controller: IETF Reference: [ RFC-to-be ] Claim Name: measres Claim Description: The results of comparing software measurements to reference values Change Controller: IETF Reference: [ RFC-to-be ] Claim Name: intuse Claim Description: Indicates intended use of the EAT Change Controller: IETF Reference: [ RFC-to-be ] PLEASE NOTE: JSON Web Token Claims registration requests should be sent to the mailing list described in [RFC7519] for review. We will initiate this review via a separate request. If approved, designated experts will notify IANA within three weeks. This review must be completed before the document's IANA state can be changed to "IANA OK." Fourth, in the CBOR Web Token (CWT) Claims registry located at: https://www.iana.org/assignments/cwt/ ten new Claims are to be registered as follows, where the Claim Keys are to be determined starting around integer value 267: IANA QUESTION -> Would it be acceptable to list the IETF as the change controller for the JSON Web Token Claims and CBOR Web Token (CWT) Claims registrations instead of the IESG? There has been a preference for doing so, as described in the expired document at https://datatracker.ietf.org/doc/html/draft-leiba-ietf-iana-registrations-00, but it has not been recorded in a permanent document yet. Claim Name: Uptime Claim Description: Uptime JWT Claim Name: uptime Claim Key: [ TBD-at-Registration ] Claim Value Type: unsigned integer Change Controller: IETF Reference: [ RFC-to-be ] Claim Name: Boot Count Claim Description: The number times the entity or submodule has been booted JWT Claim Name: bootcount Claim Key: [ TBD-at-Registration ] Claim Value Type: uint Change Controller: IETF Reference: [ RFC-to-be ] Claim Name: Boot Seed Claim Description: Identifies a boot cycle JWT Claim Name: bootseed Claim Key: [ TBD-at-Registration ] Claim Value Type: bytes Change Controller: IETF Reference: [ RFC-to-be ] Claim Name: DLOAs Claim Description: Certifications received as Digital Letters of Approval JWT Claim Name: dloas Claim Key: [ TBD-at-Registration ] Claim Value Type: array Change Controller: IETF Reference: [ RFC-to-be ] Claim Name: Software Name Claim Description: The name of the software running in the entity JWT Claim Name: swname Claim Key: [ TBD-at-Registration ] Claim Value Type: map Change Controller: IETF Reference: [ RFC-to-be ] Claim Name: Software Version Claim Description: The version of software running in the entity JWT Claim Name: swversion Claim Key: [ TBD-at-Registration ] Claim Value Type: map Change Controller: IETF Reference: [ RFC-to-be ] Claim Name: Software Manifests Claim Description: Manifests describing the software installed on the entity JWT Claim Name: manifests Claim Key: [ TBD-at-Registration ] Claim Value Type: array Change Controller: IETF Reference: [ RFC-to-be ] Claim Name: Measurements Claim Description: Measurements of the software, memory configuration and such on the entity JWT Claim Name: measurements Claim Key: [ TBD-at-Registration ] Claim Value Type: array Change Controller: IETF Reference: [ RFC-to-be ] Claim Name: Software Measurement Results Claim Description: The results of comparing software measurements to reference values JWT Claim Name: measres Claim Key: [ TBD-at-Registration ] Claim Value Type: array Change Controller: IETF Reference: [ RFC-to-be ] Claim Name: Intended Use Claim Description: Indicates intended use of the EAT JWT Claim Name: intuse Claim Key: [ TBD-at-Registration ] Claim Value Type: integer or string Change Controller: IETF Reference: [ RFC-to-be ] PLEASE NOTE: CBOR Web Token (CWT) Claims registration requests should be sent to the mailing list described in [RFC8392] for review. We will initiate this review to the mailing list via a separate request. If approved, designated experts will notify IANA within three weeks. This review must be completed before the document's IANA state can be changed to "IANA OK." Fifth, in the JSON Web Token Claims registry in the JSON Web Token (JWT) registry group located at: https://www.iana.org/assignments/jwt/ the existing registration for: Claim Name: secboot Claim Description: Indicate whether the boot was secure Change Controller: IESG Reference: [ RFC-to-be ] will be changed to: Claim Name: oemboot Claim Description: Indicate whether the software booted was OEM authorized Change Controller: IETF Reference: [ RFC-to-be ] IANA QUESTION -> Should the description be changed to "Indicates whether the software booted was OEM authorized"? Sixth, in the CBOR Web Token (CWT) Claims registry located at: https://www.iana.org/assignments/cwt/ the existing registration for: Claim Name: Secure Boot Claim Description: Indicate whether the boot was secure JWT Claim Name: secboot Claim Key: 262 Claim Value Type: Boolean Change Controller: IESG Reference: [ RFC-to-be ] will be changed to: Claim Name: OEM Authortised Boot Claim Description: Indicate whether the software booted was OEM authorized JWT Claim Name: oemboot Claim Key: 262 Claim Value Type: Boolean Change Controller: IETF Reference: [ RFC-to-be ] IANA QUESTION -> Should the Claim Name be changed to "OEM Authorized Boot" instead, or is "OEM Authortised Boot" correct? Also, should the description be changed to "Indicates whether the software booted was OEM authorized"? Seventh, in the DEV URN Subtypes registry in the Device Identification registry group located at: https://www.iana.org/assignments/device-identification/ two new registrations are to be made as follows: Subtype: ueid Description: Universal Entity Identifier Reference: [ RFC-to-be ] Subtype: sueid Description: Semi-permanent Universal Entity Identifier Reference: [ RFC-to-be ] As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." Eighth, in the CBOR Tags registry located at: https://www.iana.org/assignments/cbor-tags/ a single new registration will be made from the First Come, First Served range of the registry as follows: Tag: [ TBD-at-Registration ] Data Item: array Semantics: Detached EAT Bundle Reference: [ RFC-to-be, Section 5 ] Template: NOTE: Registrations in the CBOR Tags registry require the template defined in section 9.2 of RFC 8949. The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. For definitions of IANA review states, please see: https://datatracker.ietf.org/help/state/draft/iana-review Thank you, David Dong IANA Services Sr. Specialist |
2023-08-02
|
21 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Linda Dunbar |
2023-07-20
|
21 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ines Robles |
2023-07-20
|
21 | Barry Leiba | Request for Last Call review by ARTART is assigned to Jaime Jimenez |
2023-07-20
|
21 | Barry Leiba | Assignment of request for Last Call review by ARTART to Thomas Fossati was rejected |
2023-07-19
|
21 | Barry Leiba | Request for Last Call review by ARTART is assigned to Thomas Fossati |
2023-07-19
|
21 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2023-07-19
|
21 | Cindy Morgan | The following Last Call announcement was sent out (ends 2023-08-09): From: The IESG To: IETF-Announce CC: draft-ietf-rats-eat@ietf.org, ned.smith@intel.com, rats-chairs@ietf.org, rats@ietf.org, rdd@cert.org … The following Last Call announcement was sent out (ends 2023-08-09): From: The IESG To: IETF-Announce CC: draft-ietf-rats-eat@ietf.org, ned.smith@intel.com, rats-chairs@ietf.org, rats@ietf.org, rdd@cert.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (The Entity Attestation Token (EAT)) to Proposed Standard The IESG has received a request from the Remote ATtestation ProcedureS WG (rats) to consider the following document: - 'The Entity Attestation Token (EAT)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2023-08-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract An Entity Attestation Token (EAT) provides an attested claims set that describes state and characteristics of an entity, a device like a smartphone, IoT device, network equipment or such. This claims set is used by a relying party, server or service to determine how much it wishes to trust the entity. An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rats-eat/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc8792: Handling Long Lines in Content of Internet-Drafts and RFCs (Informational - Internet Engineering Task Force (IETF)) |
2023-07-19
|
21 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2023-07-19
|
21 | Cindy Morgan | Last call announcement was changed |
2023-07-19
|
21 | Roman Danyliw | Last call was requested |
2023-07-19
|
21 | Roman Danyliw | Last call announcement was generated |
2023-07-19
|
21 | Roman Danyliw | Ballot approval text was generated |
2023-07-19
|
21 | Roman Danyliw | Ballot writeup was generated |
2023-07-19
|
21 | Roman Danyliw | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2023-06-30
|
21 | (System) | Changed action holders to Roman Danyliw (IESG state changed) |
2023-06-30
|
21 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2023-06-30
|
21 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-21.txt |
2023-06-30
|
21 | (System) | New version approved |
2023-06-30
|
21 | (System) | Request for posting confirmation emailed to previous authors: Carl Wallace , Giridhar Mandyam , Jeremy O'Donoghue , Laurence Lundblade |
2023-06-30
|
21 | Giridhar Mandyam | Uploaded new revision |
2023-06-22
|
20 | (System) | Changed action holders to Laurence Lundblade, Giridhar Mandyam, Jeremy O'Donoghue, Carl Wallace, Roman Danyliw (IESG state changed) |
2023-06-22
|
20 | Roman Danyliw | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2023-06-22
|
20 | Roman Danyliw | AD re-review on -20 at https://mailarchive.ietf.org/arch/msg/rats/wuRFnZKg2nhSjW0-JlYz06EaEkg/ |
2023-06-13
|
20 | (System) | Changed action holders to Roman Danyliw (IESG state changed) |
2023-06-13
|
20 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2023-06-13
|
20 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-20.txt |
2023-06-13
|
20 | (System) | New version approved |
2023-06-13
|
20 | (System) | Request for posting confirmation emailed to previous authors: Carl Wallace , Giridhar Mandyam , Jeremy O'Donoghue , Laurence Lundblade |
2023-06-13
|
20 | Giridhar Mandyam | Uploaded new revision |
2023-03-17
|
19 | Roman Danyliw | AD Review: https://mailarchive.ietf.org/arch/msg/rats/50ZbUkhSrU1cgOLYkir3f1kKFiY/ |
2023-03-17
|
19 | (System) | Changed action holders to Laurence Lundblade, Roman Danyliw, Carl Wallace, Giridhar Mandyam, Jeremy O'Donoghue (IESG state changed) |
2023-03-17
|
19 | Roman Danyliw | IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested |
2023-01-24
|
19 | Ned Smith | # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the … # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the responsibilities is answering the questions in this write-up to give helpful context to Last Call and Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in completing it is appreciated. The full role of the shepherd is further described in [RFC 4858][2]. You will need the cooperation of the authors and editors to complete these checks. Note that some numbered items contain multiple related questions; please be sure to answer all of them. ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? While there was strong contribution of small group, there was broad consensus to move with the current version of the draft. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? Intial versions of the draft were too broad in scope, the resulting draft is the content That reached broad consensus 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? Known or planned implementations of EAT or a profile of EAT: EAT Libraries: - CBOR Formats - open source project o Rust: https://github.com/carl-wallace/cbor_formats - EAT library - open source project o C: https://github.com/laurencelundblade/ctoken - A command line utility based on EAT library - open source project o C: https://github.com/laurencelundblade/xclaim EAT Profiles: - PSA o Golang: https://github.com/veraison/psatoken o C: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/partitions/initial_attestation o Python: https://git.trustedfirmware.org/TF-M/tf-m-tools.git/tree/iat-verifier - CCA o Golang: https://github.com/veraison/ccatoken o C: https://git.trustedfirmware.org/TF-RMM/tf-rmm.git/tree/lib/attestation - FIDO FDO - open source project o Java: https://github.com/secure-device-onboard/pri-fidoiot/blob/master/protocol/src/main/java/org/fidoalliance/fdo/protocol/message/EatPayloadBase.java. - Global Platform - very early code of an EAT profile, may evolve into open source o https://github.com/GlobalPlatform/TPS-API-Reference-Implementations. - Microsoft Azure Attestation - proprietary o https://github.com/CCC-Attestation/meetings/blob/main/materials/GregKostal_EAT_in_MAA.pdf ## Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. Yes, there is close relation to other drafts in RATS (e.g., UCCS and the RATS Architecture), more importantly it leverages the work from (ACE/JOSE/COSE) as it uses JWT and CWTs and generates extensions to those groups. There is also alignment with the FIDO Alliance organization as they look to leverage the claims defined in this draft. 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The draft has acquired early IANA assignment as well as expert review on the Oauth/JWT and CWT. See answer to #21. 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? No, YANG is not used or specified in this draft. 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. We cloned and built the EAT github repository locally which is based on the Thomson template (martinthomson/i-d-template: A template for IETF internet draft git repositories (github.com)) and it built without errors, but with one warning that identified a unused informative reference. There was one informative reference to a draft that has since become an RFC that should be updated. The eat draft relies on CDDL for normative statements. The CDDL is verified correct using a make file that checks the CDDL against examples. The same CDDL files are imported into the draft giving high confidence they are syntactically correct. ## Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? I have reviewed the document and believe it is ready for Area Directory review. The EAT I-D is a set of claims that are intended for use within a CWT or JWT web token. There aren’t any mandatory to use claims as their use is prescribed according to a profile that may be user, application, or vendor specific. The intent of the draft is to define claim syntax and semantics such that if a claim is asserted by one entity, a receiving entity will be able to process the claim by reading the EAT draft. The RATS Architecture RFC 9334: Remote ATtestation procedureS (RATS) Architecture (ietf.org) defines several attestation conceptual messages. Claims contained in the EAT draft could be used by some or all the conceptual messages. There may be claims defined in EAT that are better suited to one type of conceptual message over another, but it was not a goal of the draft to stereo type the claims to conceptual messages. There were several discussions on the email list and in face-to-face meetings to clarify these objectives. Some of the proposed claims were less well defined or thought to be unnecessary and were removed from the final draft. Other claims were thought to be highly useful, such that the working group sought and obtained early allocation from IANA registries. The FIDO Alliance has incorporated some of the early allocation claims into at least one of their specifications. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? This draft received reviews from SECDir and IoTdir representatives. One issue raised was an interoperability concern. If a profile is required to direct which claims are used and, in some cases, how they are to be applied, wouldn’t that suggest that the profile is point at which interoperability is guaranteed. The working group resolved this issue by observing that all web tokens require similar qualification. As a building block specification, it is anticipated that other standards groups will write specifications that define meaningful profiles, but it is also possible that vendor-specific profiles could be defined as well. There is a public vendor specific profile here: draft-tschofenig-rats-psa-token-10 - Arm's Platform Security Architecture (PSA) Attestation Token (ietf.org). Another concern raised had to do with the way certain claims were described, and whether the description was semantically clear and sufficient to avoid downstream security issues. The authors addressed these concerns by rewriting the section or by removing the claim altogether (possibly to be reintroduced in a future draft). Some of the feedback observed that EAT refers to attestation ‘protocols’ where that may be too specific as the RATS Architecture refers to them as ‘conveyance’ mechanisms. The EAT draft does not intend to define a protocol per se but does anticipate being used to define a conceptual message type that is included as a payload in a protocol that supports attestation. Still other review feedback included concerns about possible semantic differences that could occur given different conceptual message contexts. A claim asserted as Evidence could have different meaning if asserted as Attestation Results, for example. The working group resolved these concerns by revising EAT normative that seemed to prescribe a meaning assuming a particular conceptual message type but didn’t clearly articulate the assumption as part of the description. 11. What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? Request is for “Proposed Standard”, the datatracker and draft reflect the intent. 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][7]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. Yes, we did a query to the RATs mail list as well as a unicast request to the draft authors and no IPR disclosures were submitted or known to the participants. 13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. Yes. 14. Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) The EAT draft appears to follow the I-D style guidelines and uses the convention that “this document” should be replaced with “this RFC” when an RFC status is granted. It makes use of acronyms by defining the expanded name and including a parenthetical abbreviation. The draft appears to make proper use of RFC2119 for normative statements. The draft appears to follow guidelines in NISTIR8366. There doesn’t appear to be stale text. 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. The RATS chairs identified two informative references [IEEE.802-2001] and [OUI.Guide] that possibly should be normative. The chairs notified the authors to determine if this is appropriate. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? All normative references are freely available. 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them. There are 4 normative references to non-standards track RFCs: RFC2119, RFC8126, RFC8174, RFC8792 and two references to I-Ds: https://datatracker.ietf.org/doc/html/draft-ietf-suit-manifest-21 and https://datatracker.ietf.org/doc/html/draft-ietf-sacm-coswid-22. 18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? The two cited I-Ds are progressing toward RFC status. This I-D should update these references when they become RFCs. RFC9052 and RFC8949 make normative reference to RFC2119 and RFC8174. Possibly, these should be added to the downref exceptions registry Downref registry (ietf.org)? The I-D authors believe RFC8126 and RFC8792 do not need to be normative references. They plan to make this change in v20 of the EAT draft. 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. No 20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]). The IANA considerations section identifies the code points that have been previously assigned based on a pre-allocation request and the remaining code points are clearly described as requiring IANA allocation. 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. There are several IANA registries that are impacted by this I-D. Michael Jones would be the appropriate designated expert. The set of IANA registries affected are copied from the EAT draft as follows: 10.2. CWT and JWT Claims Registered by This Document This specification adds the following values to the "JSON Web Token Claims" registry established by [RFC7519] and the "CBOR Web Token Claims Registry" established by [RFC8392]. Each entry below is an addition to both registries.¶ The "Claim Description", "Change Controller" and "Specification Documents" are common and equivalent for the JWT and CWT registries. The "Claim Key" and "Claim Value Types(s)" are for the CWT registry only. The "Claim Name" is as defined for the CWT registry, not the JWT registry. The "JWT Claim Name" is equivalent to the "Claim Name" in the JWT registry. IANA is requested to register the following claims. RFC Editor: Please make the following adjustments and remove this paragraph. Replace "this document" with this RFC number. In the following, the claims with "Claim Key: TBD" need to be assigned a value in the Specification Required Range, preferrably starting around 267. Those below already with a Claim Key number were given early assignment. No change is requested for them except for Claim Key 262. Claim 262 should be renamed from "secboot" to "oemboot" in the JWT registry and it's description changed in both the CWT and JWT registries. • Claim Name: Nonce¶ • Claim Description: Nonce¶ • JWT Claim Name: "eat_nonce"¶ • Claim Key: 10¶ • Claim Value Type(s): byte string¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: UEID¶ • Claim Description: The Universal Entity ID¶ • JWT Claim Name: "ueid"¶ • CWT Claim Key: 256¶ • Claim Value Type(s): byte string¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: SUEIDs¶ • Claim Description: Semi-permanent UEIDs¶ • JWT Claim Name: "sueids"¶ • CWT Claim Key: 257¶ • Claim Value Type(s): map¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Hardware OEMID¶ • Claim Description: Hardware OEM ID¶ • JWT Claim Name: "oemid"¶ • Claim Key: 258¶ • Claim Value Type(s): byte string or integer¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Hardware Model¶ • Claim Description: Model identifier for hardware¶ • JWT Claim Name: "hwmodel"¶ • Claim Key: 259¶ • Claim Value Type(s): byte string¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Hardware Version¶ • Claim Description: Hardware Version Identifier¶ • JWT Claim Name: "hwversion"¶ • Claim Key: TBD 260¶ • Claim Value Type(s): array¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: OEM Authortised Boot¶ • Claim Description: Indicate whether the software booted was OEM authorized¶ • JWT Claim Name: "oemboot"¶ • Claim Key: 262¶ • Claim Value Type(s): Boolean¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Debug Status¶ • Claim Description: Indicate status of debug facilities¶ • JWT Claim Name: "dbgstat"¶ • Claim Key: 263¶ • Claim Value Type(s): integer or string¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Location¶ • Claim Description: The geographic location¶ • JWT Claim Name: "location"¶ • Claim Key: 264¶ • Claim Value Type(s): map¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: EAT Profile¶ • Claim Description: Indicates the EAT profile followed¶ • JWT Claim Name: "eat_profile"¶ • Claim Key: 265¶ • Claim Value Type(s): URI or OID¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Submodules Section¶ • Claim Description: The section containing submodules¶ • JWT Claim Name: "submods"¶ • Claim Key: 266¶ • Claim Value Type(s): map¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Uptime¶ • Claim Description: Uptime¶ • JWT Claim Name: "uptime"¶ • Claim Key: TBD¶ • Claim Value Type(s): unsigned integer¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Boot Count¶ • Claim Description: The number times the entity or submodule has been booted¶ • JWT Claim Name: "bootcount"¶ • Claim Key: TBD¶ • Claim Value Type(s): uint¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Boot Seed¶ • Claim Description: Identifies a boot cycle¶ • JWT Claim Name: "bootseed"¶ • Claim Key: TBD¶ • Claim Value Type(s): bytes¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: DLOAs¶ • Claim Description: Certifications received as Digital Letters of Approval¶ • JWT Claim Name: "dloas"¶ • Claim Key: TBD¶ • Claim Value Type(s): array¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Software Name¶ • Claim Description: The name of the software running in the entity¶ • JWT Claim Name: "swname"¶ • Claim Key: TBD¶ • Claim Value Type(s): map¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Software Version¶ • Claim Description: The version of software running in the entity¶ • JWT Claim Name: "swversion"¶ • Claim Key: TBD¶ • Claim Value Type(s): map¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Software Manifests¶ • Claim Description: Manifests describing the software installed on the entity¶ • JWT Claim Name: "manifests"¶ • Claim Key: TBD¶ • Claim Value Type(s): array¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Measurements¶ • Claim Description: Measurements of the software, memory configuration and such on the entity¶ • JWT Claim Name: "measurements"¶ • Claim Key: TBD¶ • Claim Value Type(s): array¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Software Measurement Results¶ • Claim Description: The results of comparing software measurements to reference values¶ • JWT Claim Name: "measres"¶ • Claim Key: TBD¶ • Claim Value Type(s): array¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Intended Use¶ • Claim Description: Indicates intended use of the EAT¶ • JWT Claim Name: "intuse"¶ • Claim Key: TBD¶ • Claim Value Type(s): integer or string¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ 10.3. UEID URN Registered by this Document IANA is requested to register the following new subtypes in the "DEV URN Subtypes" registry under "Device Identification". See [RFC9039].¶ Table 3 Subtype Description Reference ueid Universal Entity Identifier This document sueid Semi-permanent Universal Entity Identifier This document 10.4. CBOR Tag for Detached EAT Bundle Registered by this Document In the registry [IANA.cbor-tags], IANA is requested to allocate the following tag from the FCFS space, with the present document as the specification reference.¶ Table 4 Tag Data Items Semantics TBD602 array Detached EAT Bundle Section 5 10.5. Media Types Registered by this Document It is requested that the CoAP Content-Format for SPDX and CycloneDX be been registered in the "CoAP Content-Formats" subregistry within the "Constrained RESTful Environments (CoRE) Parameters" registry [IANA.core-parameters]:¶ • Media Type: application/spdx+json¶ • Encoding: binary¶ • ID: TBD¶ • Reference: [SPDX]¶ • Media Type: vendor/vnd.cyclonedx+xml¶ • Encoding: binary¶ • ID: TBD¶ • Reference: [CycloneDX]¶ • Media Type: vendor/vnd.cyclonedx+json¶ • Encoding: binary¶ • ID: TBD¶ • Reference: [CycloneDX] [1]: https://www.ietf.org/about/groups/iesg/ [2]: https://www.rfc-editor.org/rfc/rfc4858.html [3]: https://www.rfc-editor.org/rfc/rfc7942.html [4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp79 [8]: https://www.ietf.org/tools/idnits/ [9]: https://www.rfc-editor.org/rfc/rfc3967.html [10]: https://www.rfc-editor.org/info/bcp97 [11]: https://www.rfc-editor.org/rfc/rfc8126.html [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]: https://authors.ietf.org/en/content-guidelines-overview [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ [17]: https://datatracker.ietf.org/doc/downref/ |
2023-01-24
|
19 | Ned Smith | Responsible AD changed to Roman Danyliw |
2023-01-24
|
19 | Ned Smith | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2023-01-24
|
19 | Ned Smith | IESG state changed to Publication Requested from I-D Exists |
2023-01-24
|
19 | Ned Smith | Document is now in IESG state Publication Requested |
2023-01-24
|
19 | Ned Smith | Changed consensus to Yes from Unknown |
2023-01-24
|
19 | Ned Smith | Intended Status changed to Proposed Standard from None |
2023-01-23
|
19 | Ned Smith | # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the … # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the responsibilities is answering the questions in this write-up to give helpful context to Last Call and Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in completing it is appreciated. The full role of the shepherd is further described in [RFC 4858][2]. You will need the cooperation of the authors and editors to complete these checks. Note that some numbered items contain multiple related questions; please be sure to answer all of them. ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? While there was strong contribution of small group, there was broad consensus to move with the current version of the draft. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? Intial versions of the draft were too broad in scope, the resulting draft is the content That reached broad consensus 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? Known or planned implementations of EAT or a profile of EAT: EAT Libraries: - CBOR Formats - open source project o Rust: https://github.com/carl-wallace/cbor_formats - EAT library - open source project o C: https://github.com/laurencelundblade/ctoken - A command line utility based on EAT library - open source project o C: https://github.com/laurencelundblade/xclaim EAT Profiles: - PSA o Golang: https://github.com/veraison/psatoken o C: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/partitions/initial_attestation o Python: https://git.trustedfirmware.org/TF-M/tf-m-tools.git/tree/iat-verifier - CCA o Golang: https://github.com/veraison/ccatoken o C: https://git.trustedfirmware.org/TF-RMM/tf-rmm.git/tree/lib/attestation - FIDO FDO - open source project o Java: https://github.com/secure-device-onboard/pri-fidoiot/blob/master/protocol/src/main/java/org/fidoalliance/fdo/protocol/message/EatPayloadBase.java. - Global Platform - very early code of an EAT profile, may evolve into open source o https://github.com/GlobalPlatform/TPS-API-Reference-Implementations. - Microsoft Azure Attestation - proprietary o https://github.com/CCC-Attestation/meetings/blob/main/materials/GregKostal_EAT_in_MAA.pdf ## Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. Yes, there is close relation to other drafts in RATS (e.g., UCCS and the RATS Architecture), more importantly it leverages the work from (ACE/JOSE/COSE) as it uses JWT and CWTs and generates extensions to those groups. There is also alignment with the FIDO Alliance organization as they look to leverage the claims defined in this draft. 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The draft has acquired early IANA assignment as well as expert review on the Oauth/JWT and CWT. See answer to #21. 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? No, YANG is not used or specified in this draft. 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. We cloned and built the EAT github repository locally which is based on the Thomson template (martinthomson/i-d-template: A template for IETF internet draft git repositories (github.com)) and it built without errors, but with one warning that identified a unused informative reference. There was one informative reference to a draft that has since become an RFC that should be updated. The eat draft relies on CDDL for normative statements. The CDDL is verified correct using a make file that checks the CDDL against examples. The same CDDL files are imported into the draft giving high confidence they are syntactically correct. ## Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? I have reviewed the document and believe it is ready for Area Directory review. The EAT I-D is a set of claims that are intended for use within a CWT or JWT web token. There aren’t any mandatory to use claims as their use is prescribed according to a profile that may be user, application, or vendor specific. The intent of the draft is to define claim syntax and semantics such that if a claim is asserted by one entity, a receiving entity will be able to process the claim by reading the EAT draft. The RATS Architecture RFC 9334: Remote ATtestation procedureS (RATS) Architecture (ietf.org) defines several attestation conceptual messages. Claims contained in the EAT draft could be used by some or all the conceptual messages. There may be claims defined in EAT that are better suited to one type of conceptual message over another, but it was not a goal of the draft to stereo type the claims to conceptual messages. There were several discussions on the email list and in face-to-face meetings to clarify these objectives. Some of the proposed claims were less well defined or thought to be unnecessary and were removed from the final draft. Other claims were thought to be highly useful, such that the working group sought and obtained early allocation from IANA registries. The FIDO Alliance has incorporated some of the early allocation claims into at least one of their specifications. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? This draft received reviews from SECDir and IoTdir representatives. One issue raised was an interoperability concern. If a profile is required to direct which claims are used and, in some cases, how they are to be applied, wouldn’t that suggest that the profile is point at which interoperability is guaranteed. The working group resolved this issue by observing that all web tokens require similar qualification. As a building block specification, it is anticipated that other standards groups will write specifications that define meaningful profiles, but it is also possible that vendor-specific profiles could be defined as well. There is a public vendor specific profile here: draft-tschofenig-rats-psa-token-10 - Arm's Platform Security Architecture (PSA) Attestation Token (ietf.org). Another concern raised had to do with the way certain claims were described, and whether the description was semantically clear and sufficient to avoid downstream security issues. The authors addressed these concerns by rewriting the section or by removing the claim altogether (possibly to be reintroduced in a future draft). Some of the feedback observed that EAT refers to attestation ‘protocols’ where that may be too specific as the RATS Architecture refers to them as ‘conveyance’ mechanisms. The EAT draft does not intend to define a protocol per se but does anticipate being used to define a conceptual message type that is included as a payload in a protocol that supports attestation. Still other review feedback included concerns about possible semantic differences that could occur given different conceptual message contexts. A claim asserted as Evidence could have different meaning if asserted as Attestation Results, for example. The working group resolved these concerns by revising EAT normative that seemed to prescribe a meaning assuming a particular conceptual message type but didn’t clearly articulate the assumption as part of the description. 11. What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? Request is for “Proposed Standard”, the datatracker and draft reflect the intent. 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][7]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. Yes, we did a query to the RATs mail list as well as a unicast request to the draft authors and no IPR disclosures were submitted or known to the participants. 13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. Yes. 14. Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) The EAT draft appears to follow the I-D style guidelines and uses the convention that “this document” should be replaced with “this RFC” when an RFC status is granted. It makes use of acronyms by defining the expanded name and including a parenthetical abbreviation. The draft appears to make proper use of RFC2119 for normative statements. The draft appears to follow guidelines in NISTIR8366. There doesn’t appear to be stale text. 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. The RATS chairs identified two informative references [IEEE.802-2001] and [OUI.Guide] that possibly should be normative. The chairs notified the authors to determine if this is appropriate. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? All normative references are freely available. 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them. There are 4 normative references to non-standards track RFCs: RFC2119, RFC8126, RFC8174, RFC8792 and two references to I-Ds: https://datatracker.ietf.org/doc/html/draft-ietf-suit-manifest-21 and https://datatracker.ietf.org/doc/html/draft-ietf-sacm-coswid-22. 18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? The two cited I-Ds are progressing toward RFC status. This I-D should update these references when they become RFCs. RFC9052 and RFC8949 make normative reference to RFC2119 and RFC8174. Possibly, these should be added to the downref exceptions registry Downref registry (ietf.org)? The I-D authors believe RFC8126 and RFC8792 do not need to be normative references. They plan to make this change in v20 of the EAT draft. 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. No 20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]). The IANA considerations section identifies the code points that have been previously assigned based on a pre-allocation request and the remaining code points are clearly described as requiring IANA allocation. 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. There are several IANA registries that are impacted by this I-D. Michael Jones would be the appropriate designated expert. The set of IANA registries affected are copied from the EAT draft as follows: 10.2. CWT and JWT Claims Registered by This Document This specification adds the following values to the "JSON Web Token Claims" registry established by [RFC7519] and the "CBOR Web Token Claims Registry" established by [RFC8392]. Each entry below is an addition to both registries.¶ The "Claim Description", "Change Controller" and "Specification Documents" are common and equivalent for the JWT and CWT registries. The "Claim Key" and "Claim Value Types(s)" are for the CWT registry only. The "Claim Name" is as defined for the CWT registry, not the JWT registry. The "JWT Claim Name" is equivalent to the "Claim Name" in the JWT registry. IANA is requested to register the following claims. RFC Editor: Please make the following adjustments and remove this paragraph. Replace "this document" with this RFC number. In the following, the claims with "Claim Key: TBD" need to be assigned a value in the Specification Required Range, preferrably starting around 267. Those below already with a Claim Key number were given early assignment. No change is requested for them except for Claim Key 262. Claim 262 should be renamed from "secboot" to "oemboot" in the JWT registry and it's description changed in both the CWT and JWT registries. • Claim Name: Nonce¶ • Claim Description: Nonce¶ • JWT Claim Name: "eat_nonce"¶ • Claim Key: 10¶ • Claim Value Type(s): byte string¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: UEID¶ • Claim Description: The Universal Entity ID¶ • JWT Claim Name: "ueid"¶ • CWT Claim Key: 256¶ • Claim Value Type(s): byte string¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: SUEIDs¶ • Claim Description: Semi-permanent UEIDs¶ • JWT Claim Name: "sueids"¶ • CWT Claim Key: 257¶ • Claim Value Type(s): map¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Hardware OEMID¶ • Claim Description: Hardware OEM ID¶ • JWT Claim Name: "oemid"¶ • Claim Key: 258¶ • Claim Value Type(s): byte string or integer¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Hardware Model¶ • Claim Description: Model identifier for hardware¶ • JWT Claim Name: "hwmodel"¶ • Claim Key: 259¶ • Claim Value Type(s): byte string¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Hardware Version¶ • Claim Description: Hardware Version Identifier¶ • JWT Claim Name: "hwversion"¶ • Claim Key: TBD 260¶ • Claim Value Type(s): array¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: OEM Authortised Boot¶ • Claim Description: Indicate whether the software booted was OEM authorized¶ • JWT Claim Name: "oemboot"¶ • Claim Key: 262¶ • Claim Value Type(s): Boolean¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Debug Status¶ • Claim Description: Indicate status of debug facilities¶ • JWT Claim Name: "dbgstat"¶ • Claim Key: 263¶ • Claim Value Type(s): integer or string¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Location¶ • Claim Description: The geographic location¶ • JWT Claim Name: "location"¶ • Claim Key: 264¶ • Claim Value Type(s): map¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: EAT Profile¶ • Claim Description: Indicates the EAT profile followed¶ • JWT Claim Name: "eat_profile"¶ • Claim Key: 265¶ • Claim Value Type(s): URI or OID¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Submodules Section¶ • Claim Description: The section containing submodules¶ • JWT Claim Name: "submods"¶ • Claim Key: 266¶ • Claim Value Type(s): map¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Uptime¶ • Claim Description: Uptime¶ • JWT Claim Name: "uptime"¶ • Claim Key: TBD¶ • Claim Value Type(s): unsigned integer¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Boot Count¶ • Claim Description: The number times the entity or submodule has been booted¶ • JWT Claim Name: "bootcount"¶ • Claim Key: TBD¶ • Claim Value Type(s): uint¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Boot Seed¶ • Claim Description: Identifies a boot cycle¶ • JWT Claim Name: "bootseed"¶ • Claim Key: TBD¶ • Claim Value Type(s): bytes¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: DLOAs¶ • Claim Description: Certifications received as Digital Letters of Approval¶ • JWT Claim Name: "dloas"¶ • Claim Key: TBD¶ • Claim Value Type(s): array¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Software Name¶ • Claim Description: The name of the software running in the entity¶ • JWT Claim Name: "swname"¶ • Claim Key: TBD¶ • Claim Value Type(s): map¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Software Version¶ • Claim Description: The version of software running in the entity¶ • JWT Claim Name: "swversion"¶ • Claim Key: TBD¶ • Claim Value Type(s): map¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Software Manifests¶ • Claim Description: Manifests describing the software installed on the entity¶ • JWT Claim Name: "manifests"¶ • Claim Key: TBD¶ • Claim Value Type(s): array¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Measurements¶ • Claim Description: Measurements of the software, memory configuration and such on the entity¶ • JWT Claim Name: "measurements"¶ • Claim Key: TBD¶ • Claim Value Type(s): array¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Software Measurement Results¶ • Claim Description: The results of comparing software measurements to reference values¶ • JWT Claim Name: "measres"¶ • Claim Key: TBD¶ • Claim Value Type(s): array¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ • Claim Name: Intended Use¶ • Claim Description: Indicates intended use of the EAT¶ • JWT Claim Name: "intuse"¶ • Claim Key: TBD¶ • Claim Value Type(s): integer or string¶ • Change Controller: IESG¶ • Specification Document(s): this document¶ 10.3. UEID URN Registered by this Document IANA is requested to register the following new subtypes in the "DEV URN Subtypes" registry under "Device Identification". See [RFC9039].¶ Table 3 Subtype Description Reference ueid Universal Entity Identifier This document sueid Semi-permanent Universal Entity Identifier This document 10.4. CBOR Tag for Detached EAT Bundle Registered by this Document In the registry [IANA.cbor-tags], IANA is requested to allocate the following tag from the FCFS space, with the present document as the specification reference.¶ Table 4 Tag Data Items Semantics TBD602 array Detached EAT Bundle Section 5 10.5. Media Types Registered by this Document It is requested that the CoAP Content-Format for SPDX and CycloneDX be been registered in the "CoAP Content-Formats" subregistry within the "Constrained RESTful Environments (CoRE) Parameters" registry [IANA.core-parameters]:¶ • Media Type: application/spdx+json¶ • Encoding: binary¶ • ID: TBD¶ • Reference: [SPDX]¶ • Media Type: vendor/vnd.cyclonedx+xml¶ • Encoding: binary¶ • ID: TBD¶ • Reference: [CycloneDX]¶ • Media Type: vendor/vnd.cyclonedx+json¶ • Encoding: binary¶ • ID: TBD¶ • Reference: [CycloneDX] [1]: https://www.ietf.org/about/groups/iesg/ [2]: https://www.rfc-editor.org/rfc/rfc4858.html [3]: https://www.rfc-editor.org/rfc/rfc7942.html [4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp79 [8]: https://www.ietf.org/tools/idnits/ [9]: https://www.rfc-editor.org/rfc/rfc3967.html [10]: https://www.rfc-editor.org/info/bcp97 [11]: https://www.rfc-editor.org/rfc/rfc8126.html [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]: https://authors.ietf.org/en/content-guidelines-overview [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ [17]: https://datatracker.ietf.org/doc/downref/ |
2023-01-10
|
19 | Nancy Cam-Winget | Notification list changed to ned.smith@intel.com because the document shepherd was set |
2023-01-10
|
19 | Nancy Cam-Winget | Document shepherd changed to Ned Smith |
2022-12-19
|
19 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-19.txt |
2022-12-19
|
19 | (System) | New version approved |
2022-12-19
|
19 | (System) | Request for posting confirmation emailed to previous authors: Carl Wallace , Giridhar Mandyam , Jeremy O'Donoghue , Laurence Lundblade |
2022-12-19
|
19 | Giridhar Mandyam | Uploaded new revision |
2022-12-04
|
18 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-18.txt |
2022-12-04
|
18 | (System) | New version approved |
2022-12-04
|
18 | (System) | Request for posting confirmation emailed to previous authors: Carl Wallace , Giridhar Mandyam , Jeremy O'Donoghue , Laurence Lundblade |
2022-12-04
|
18 | Giridhar Mandyam | Uploaded new revision |
2022-10-31
|
17 | Ned Smith | Added to session: IETF-115: rats Mon-1530 |
2022-10-22
|
17 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-17.txt |
2022-10-22
|
17 | (System) | New version approved |
2022-10-22
|
17 | (System) | Request for posting confirmation emailed to previous authors: Carl Wallace , Giridhar Mandyam , Jeremy O'Donoghue , Laurence Lundblade |
2022-10-22
|
17 | Giridhar Mandyam | Uploaded new revision |
2022-10-09
|
16 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-16.txt |
2022-10-09
|
16 | (System) | New version approved |
2022-10-09
|
16 | (System) | Request for posting confirmation emailed to previous authors: Carl Wallace , Giridhar Mandyam , Jeremy O'Donoghue , Laurence Lundblade |
2022-10-09
|
16 | Giridhar Mandyam | Uploaded new revision |
2022-10-01
|
15 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-15.txt |
2022-10-01
|
15 | (System) | New version approved |
2022-10-01
|
15 | (System) | Request for posting confirmation emailed to previous authors: Giridhar Mandyam , Jeremy O'Donoghue , Laurence Lundblade , rats-chairs@ietf.org |
2022-10-01
|
15 | Giridhar Mandyam | Uploaded new revision |
2022-07-23
|
14 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Hilarie Orman. Submission of review completed at an earlier date. |
2022-07-21
|
14 | Ned Smith | Added to session: IETF-114: rats Mon-1000 |
2022-07-15
|
14 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Hilarie Orman. |
2022-07-10
|
14 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-14.txt |
2022-07-10
|
14 | (System) | New version approved |
2022-07-10
|
14 | (System) | Request for posting confirmation emailed to previous authors: Giridhar Mandyam , Jeremy O'Donoghue , Laurence Lundblade |
2022-07-10
|
14 | Giridhar Mandyam | Uploaded new revision |
2022-06-12
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Hilarie Orman |
2022-06-12
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Hilarie Orman |
2022-06-05
|
13 | Eliot Lear | Request for Last Call review by IOTDIR Completed: Not Ready. Reviewer: Eliot Lear. Sent review to list. |
2022-05-31
|
13 | Ines Robles | Request for Last Call review by IOTDIR is assigned to Eliot Lear |
2022-05-31
|
13 | Ines Robles | Request for Last Call review by IOTDIR is assigned to Eliot Lear |
2022-05-30
|
13 | Nancy Cam-Winget | Requested Last Call review by IOTDIR |
2022-05-30
|
13 | Nancy Cam-Winget | Requested Last Call review by SECDIR |
2022-05-20
|
13 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-13.txt |
2022-05-20
|
13 | (System) | New version approved |
2022-05-20
|
13 | (System) | Request for posting confirmation emailed to previous authors: Giridhar Mandyam , Jeremy O'Donoghue , Laurence Lundblade |
2022-05-20
|
13 | Giridhar Mandyam | Uploaded new revision |
2022-03-15
|
12 | Ned Smith | Added to session: IETF-113: rats Tue-1000 |
2022-02-24
|
12 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-12.txt |
2022-02-24
|
12 | (System) | New version approved |
2022-02-24
|
12 | (System) | Request for posting confirmation emailed to previous authors: Giridhar Mandyam , Jeremy O'Donoghue , Laurence Lundblade |
2022-02-24
|
12 | Giridhar Mandyam | Uploaded new revision |
2021-11-12
|
11 | Roman Danyliw | https://mailarchive.ietf.org/arch/msg/rats/zJ-nhMArxRQUGCB-f2jFXEFiT24/ |
2021-11-12
|
11 | Roman Danyliw | IETF WG state changed to In WG Last Call from WG Document |
2021-11-08
|
11 | Roman Danyliw | Changed document external resources from: None to: github_repo https://github.com/ietf-rats-wg/eat |
2021-11-04
|
11 | Ned Smith | Added to session: IETF-112: rats Mon-1200 |
2021-10-24
|
11 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-11.txt |
2021-10-24
|
11 | (System) | New version approved |
2021-10-24
|
11 | (System) | Request for posting confirmation emailed to previous authors: Giridhar Mandyam , Jeremy O'Donoghue , Laurence Lundblade , Miguel Ballesteros , rats-chairs@ietf.org |
2021-10-24
|
11 | Giridhar Mandyam | Uploaded new revision |
2021-07-15
|
10 | Ned Smith | Added to session: IETF-111: rats Mon-1430 |
2021-06-07
|
10 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-10.txt |
2021-06-07
|
10 | (System) | New version approved |
2021-06-07
|
10 | (System) | Request for posting confirmation emailed to previous authors: Giridhar Mandyam , Jeremy O'Donoghue , Laurence Lundblade , Miguel Ballesteros |
2021-06-07
|
10 | Giridhar Mandyam | Uploaded new revision |
2021-03-08
|
09 | Ned Smith | Added to session: IETF-110: rats Wed-1530 |
2021-03-07
|
09 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-09.txt |
2021-03-07
|
09 | (System) | New version approved |
2021-03-07
|
09 | (System) | Request for posting confirmation emailed to previous authors: Giridhar Mandyam , Jeremy O'Donoghue , Laurence Lundblade , Miguel Ballesteros |
2021-03-07
|
09 | Giridhar Mandyam | Uploaded new revision |
2021-02-04
|
08 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-08.txt |
2021-02-04
|
08 | (System) | New version approved |
2021-02-04
|
08 | (System) | Request for posting confirmation emailed to previous authors: Giridhar Mandyam , Jeremy O'Donoghue , Laurence Lundblade , Miguel Ballesteros |
2021-02-04
|
08 | Giridhar Mandyam | Uploaded new revision |
2021-02-03
|
07 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-07.txt |
2021-02-03
|
07 | (System) | New version approved |
2021-02-03
|
07 | (System) | Request for posting confirmation emailed to previous authors: Giridhar Mandyam , Jeremy O'Donoghue , Laurence Lundblade , Miguel Ballesteros |
2021-02-03
|
07 | Giridhar Mandyam | Uploaded new revision |
2020-12-02
|
06 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-06.txt |
2020-12-02
|
06 | (System) | New version approved |
2020-12-02
|
06 | (System) | Request for posting confirmation emailed to previous authors: Miguel Ballesteros , Giridhar Mandyam , Jeremy O'Donoghue , Laurence Lundblade |
2020-12-02
|
06 | Giridhar Mandyam | Uploaded new revision |
2020-12-01
|
05 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-05.txt |
2020-12-01
|
05 | (System) | New version approved |
2020-12-01
|
05 | (System) | Request for posting confirmation emailed to previous authors: Laurence Lundblade , Miguel Ballesteros , Giridhar Mandyam , Jeremy O'Donoghue |
2020-12-01
|
05 | Giridhar Mandyam | Uploaded new revision |
2020-08-31
|
04 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-04.txt |
2020-08-31
|
04 | (System) | New version approved |
2020-08-31
|
04 | (System) | Request for posting confirmation emailed to previous authors: Jeremy O'Donoghue , Miguel Ballesteros , Giridhar Mandyam , Laurence Lundblade |
2020-08-31
|
04 | Giridhar Mandyam | Uploaded new revision |
2020-08-23
|
03 | (System) | Document has expired |
2020-02-20
|
03 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-03.txt |
2020-02-20
|
03 | (System) | New version approved |
2020-02-20
|
03 | (System) | Request for posting confirmation emailed to previous authors: Laurence Lundblade , Jeremy O'Donoghue , Giridhar Mandyam , Miguel Ballesteros |
2020-02-20
|
03 | Giridhar Mandyam | Uploaded new revision |
2020-01-09
|
02 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-02.txt |
2020-01-09
|
02 | (System) | New version approved |
2020-01-09
|
02 | (System) | Request for posting confirmation emailed to previous authors: Laurence Lundblade , Jeremy O'Donoghue , Giridhar Mandyam , Miguel Ballesteros |
2020-01-09
|
02 | Giridhar Mandyam | Uploaded new revision |
2020-01-05
|
01 | (System) | Document has expired |
2019-11-17
|
01 | Nancy Cam-Winget | Added to session: IETF-106: rats Tue-1520 |
2019-07-04
|
01 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-01.txt |
2019-07-04
|
01 | (System) | New version approved |
2019-07-04
|
01 | (System) | Request for posting confirmation emailed to previous authors: Laurence Lundblade , Jeremy O'Donoghue , Giridhar Mandyam , Miguel Ballesteros |
2019-07-04
|
01 | Giridhar Mandyam | Uploaded new revision |
2019-06-23
|
00 | Kathleen Moriarty | This document now replaces draft-mandyam-rats-eat instead of None |
2019-06-23
|
00 | Giridhar Mandyam | New version available: draft-ietf-rats-eat-00.txt |
2019-06-23
|
00 | (System) | WG -00 approved |
2019-06-22
|
00 | Giridhar Mandyam | Set submitter to "Giridhar Mandyam ", replaces to (none) and sent approval email to group chairs: rats-chairs@ietf.org |
2019-06-22
|
00 | Giridhar Mandyam | Uploaded new revision |