Hi! Don't be alarmed! This is just my secdir review.

Thanks for a well written document. Comments follow:

0) I ran the I-D Nits and noted there are a lot of out dated references. This one needs to be updated for sure draft-ietf-rats-eat-31 -> RFC 9711 and the others are here:

  == Outdated reference: A later version (-34) exists of
     draft-ietf-suit-manifest-33

  == Outdated reference: A later version (-23) exists of
     draft-ietf-suit-mti-09

  == Outdated reference: A later version (-15) exists of
     draft-ietf-suit-report-11

  == Outdated reference: A later version (-12) exists of
     draft-ietf-suit-trust-domains-10

  == Outdated reference: A later version (-09) exists of
     draft-ietf-rats-ar4si-08

  == Outdated reference: A later version (-14) exists of
     draft-ietf-rats-reference-interaction-models-13

  == Outdated reference: A later version (-25) exists of
     draft-ietf-suit-firmware-encryption-23

1) s3: I realize I am being super pedantic, but shouldn’t the success and error messages be called TEEP Success and Error. The following changes would align the names of the messages with the CDDL in s4; i.e., drop the “-“ and camel case it:

   $teep-message-type /= query-request
   $teep-message-type /= query-response
   $teep-message-type /= update
   $teep-message-type /= teep-success
   $teep-message-type /= teep-error

So my suggestion is OLD:

   This specification defines five messages: QueryRequest,
   QueryResponse, Update, Success, and Error.

New:

   This specification defines five messages: QueryRequest,
   QueryResponse, Update, TEEPSuccess, and TeepError.

and then throughout
s/Success/TEEPSuccess
s/Success/TEEPError

2) s4: s/$teep-message-type .within/$teep-message-type within

3) s4: The detailed message specification numbering made me wonder why you skipped 4 and then also made me wonder why there is no IANA considerations for registering $teep-type values. Is this in the works? Also, shouldn’t there be an IANA registry for  data-item-requested, err-code, mapkey, cipher suites values (non-exhaustive list)?

4) s4.2 & s4.3: The attestation bit is referred to 5 times. Where is that defined?

5) s4.2: I must be missing something fundamental here, but why is this the case for challenge in the query-request:

  It MUST be absent if the attestation bit is clear or the
  Passport model is used.

6) s4.2: Maybe add the reference to RFC 9334 here too, it’s in s5.1 too but this is where “Passport model” first pops up:

   It MUST be absent if the attestation bit is clear or the
   Passport model, see [RFC9334],  is used.

7) s4.3: Maybe add a reference to RFC 9124 for component-id:

  component-id
      A SUIT Component Identifier; see [RFC9124].

8) s5: How is this not an IANA registry entry?

9) s7.1.1: to future proof the document I would drop “(SHA-256 for the ones mandated in this document)” from bullet 2 and just refer to the profiles. When you update the profiles then you only need to do it there.

10) s8.1: I just looked at the COSE algorithm registry and -7 (ECDSA w/ SHA-256) and -8 (EdDSA) are both deprecated. I think you’re supposed to be using -51 (ESP256) and -19 (Ed25519) - based on https://datatracker.ietf.org/doc/draft-ietf-jose-fully-specified-algorithms/

11) s10: There's a lot of good stuff in the SecCons of 9397. Is it worth referring readers to those SecCons too?

12) s10: crypto: I think maybe some references are necessary to I-D.ietf-suit-mti for the suit profiles and then maybe IANA entries' references for -51 and -19 for the crypto suites? I mean what's there now does address the points, but like people ought to go look at the SecCons for the algorithms selected.

13) s10: Do you need to say something about randomness for the token?

14) s10: Do you need to say anything (like give a recommendation) for the lifetime of the token?

15) s11: I would strengthen this:

   If any mechanism
   other than EAT is used, it is up to that mechanism to specify how
   privacy is provided.

to say:

   If any mechanism
   other than EAT is used, that mechanism MUST specify how
   privacy is provided.

Cheers,
spt