Skip to main content

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:  RFC2119RFC8126, 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:  RFC2119RFC8126, 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:  RFC2119RFC8126, 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