The Entity Attestation Token (EAT)
draft-ietf-rats-eat-31

Please gloss TEE or expand on first use. Thanks.

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.

[ 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."

Thanks for working on this document. I have no issues from TSV point of view.

# É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

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