[Rats] AD Review of draft-ietf-rats-eat-19

[Roman Danyliw <[e-mail]>]

Hi!

I completed an AD review of draft-ietf-rats-eat-19.  Thank you for all of the work on this document.  My feedback is as follows:

** Please merge https://github.com/ietf-rats-wg/eat/pull/367

** EAT as a "message".  Editorial.

The text notes that EAT is a message in a number of places in the text.  For example:
-- Section 1 "An Entity Attestation Token (EAT) is a message or token made up of claims about an entity."
-- Section 3.  "An EAT is a "message", a "token", or such whose content is a Claims-Set about an entity or some number of entities"
-- Section 3. "This document also defines a new top-level message"
-- Section 5. "It  is a top-level EAT message like a CWT or JWT."

Could there be a forward reference earlier to explain that EAT is a "message" like a "CWT and JWT".  EAT is not implying any specific message flow.

** Section 1.
  The security model and goal for attestation are unique and are not
  the same as for other security standards like those for server
  authentication, user authentication and secured messaging. 

The text asserts a difference, but the distinction isn't clear to me.  Is this text noting that "attestation" is not the same as "authentication"?  

** Section 1.
  In particular, EAT provides a profile
  mechanism to be able to clearly specify the claims needed, the
  cryptographic algorithms that should be used and other for a
  particular token and use case.

-- Where in this document is the normative behavior "specify[ing] the claims needed"?  Is that the related to the eat_profile claim and Section 6?

-- Editorial. The last clause in doesn't parse for me "... and other for a particular token and use case"

** Section 1.  Editorial.  
   The entity side of an EAT implementation generates the claims and
   typically signs them with an attestation key.  

-- s/The entity side of an EAT implementation/The entity's EAT implementation/

-- s/SW defenses/software defenses/

** Section 1.1.
   Many of the claims defined in this document are claims about an
   entity, which is equivalent to an attesting environment as defined in
   [RATS.Architecture]

This link to "attesting environment" per Figure 2 of RFC9334 doesn't appear consistent.  In RFC9334, claims are about the "target environment" and "attesting environment collect[s] the values and the information to be represented in Claims by reading system registers and variables, calling into subsystems, and taking measurements on code, memory, or other relevant assets of the Target Environment."

** Section 1.1.

   An entity may be the whole device, a subsystem,
   a subsystem of a subsystem, etc.  

What is the relationship between this statement and the "layered attestation environments" and "composite device" defined in  Section 3.2 and 3.3 of RFC9334?  

** Section 1.1

    An entity also corresponds to a "system component", as defined in the
   Internet Security Glossary [RFC4949].   ...

Is this entire paragraph trying to precisely define "system component" needed in light of text in the architecture document?

** Section 1.2.  Editorial.  This bulleted item is not like the others:

it can also be described as:
...
Claims are defined in CDDL and serialized using CBOR or JSON

It is a complete sentence and the other bullets are not

** Editorial.  I would be helpful to establish somewhere early in the document or provide a forward reference to explain the difference between a token and claim-set.  Here are early references to a distinction being made without explanation.

-- Section 1. "Nesting of tokens and claims sets is accommodated for composite devices that have multiple subsystems."
-- Section 1.2. "Nesting of claims sets and tokens to represent complex and compound devices"
-- Section 1.2. "EAT defines a means for nesting tokens and claims sets to accommodate composite device"

** Section 1.2

   As with
   CWT and JWT, no claims are mandatory and claims not recognized should
   be ignored.

Is this guidance talking about EAT usage in application?  If so, I would recommend repeated and adapting the language from RFC7519, Section4:

(my restatement by substituting EAT for JWT)
The set of claims that a EAT must contain to be considered valid is context dependent and is outside the scope of this specification. Specific applications of EATs will require implementations to    understand and process some claims in particular ways.  However, in the absence of such requirements, all claims that are not understood by implementations MUST be ignored.
 
** Section 1.2
Full tokens with security envelopes may be embedded in an
   enclosing token.  The nested token and the enclosing token do not
   have to use the same encoding (e.g., a CWT may be enclosed in a JWT).

What is the difference between a "full token" and a "token"?

** Section 2.
   This document reuses terminology from RATS Architecure
   [RATS.Architecture]:
...
   Socket Group:  refers to the mechanism by which a CDDL definition is
      extended, as described in [RFC8610] and [RFC9165]

"Socket Group" is not defined in [RATS.Architecture]

** Section 3
   This
   includes the nesting of an EAT that is a different format than the
   enclosing EAT.

What is meant by "different format"?  Is it a difference application profile or is it encodings?

** Section 4.2.1 ueid claim.  Does the WG expect future extensions to this claim given the type byte?  If so, should there be an IANA registry to manage this byte?

** Section 4.2.1.
(a) 
The consumer of a UEID MUST treat a UEID as a completely opaque
   string of bytes and MUST NOT make any use of its internal structure.

(b) 
The type byte is needed to distinguish UEIDs of different types that
   by chance have the same identifier value

(c)
The type byte MUST be treated as part of the opaque
   UEID and MUST NOT be used to make use of the internal structure of
   the UEID.

It appears that the guidance in (b) to use the 'type' to distinguish different UEIDs conflicts with (a) and (c) which asserts that the UEID (of which the type is part of) are supposed to be opaque.

** Section 4.2.1.  I'm having difficulty reconciling the guidance that the UEID is opaque with the fact that type=0x2 and 0x3 have inherent structure.

** Section 4.2.2.  Typo. s/Device Indentifier/Device Identifier/

** Section 4.2.3.1.  Please provide an informative reference for SHA-256.

** Section 4.2.3.1.  What is the reasoning for providing guidance on using a hash function to generate the OEMID?  Specifically, what advantage does it provide over the first approach of choosing a number of 128-bit number at random?

** Section 4.2.3.1.  Please include a normative reference for the first instance of base64url encoding.

** Section 4.2.4.  Is it envisioned that a profile could use the hwmodel claim without the oemid?

** Section 4.2.5.  Editorial.

   The structure and sorting order of this text
   string can be specified using the version-scheme item from CoSWID
   [CoSWID].

Wouldn't it be more precise to say that the values corresponding to the "SWID/CoSWID Version Scheme Value" registry?

** Section 4.2.4 - 4.2.7:  

-- Does the presence of a swversion claim in an EAT, require that an a swname claim also be present? 

-- Same question for hwversion and hwname.

** Section 4.2.5 and 4.2.7.  Editorial.

-- 4.2.5: The structure and sorting order of this text
   string can be specified using the version-scheme item from CoSWID

-- 4.2.7:  The "swversion" claim makes use of the CoSWID version scheme data
   type

The hwversion and swversion claim both seem to be using the same CoSWID registry in the same way.  However, one is framed as "version-scheme item" and the other "version scheme data type".

** Section 4.2.9.  

   As with all claims, the absence of the "dbgstat" claim means it is
   not reported.  A conservative interpretation might assume the enabled
   state.

It isn't clear why the absence of a claim should indicate that it's value is true (i.e., dbgstat=enabled).

** Section 4.2.10.  The CDDL has an altitude-accuracy item, but the prose does not describe it.

** Section 4.2.10.  Is the unit of the timestamp item in seconds?

** Section 4.2.10.

   The
   entity MUST still have a "ticker" that can measure a time interval.
   The age is the interval between acquisition of the location data and
   token creation.

If the age and timestamp items are both optional, why is this claim putting a requirement on the entity to be able to capture something (the ticker) that doesn't need to be passed?

** Section 4.2.14.  Are there Security Considerations around retrieval of DLOA from a given URI?

** Section 4.2.15

   Some manifests may be signed by their software manufacturer before
   they are put into this EAT claim.  When such manifests are put into
   this claim, the manufacturer's signature SHOULD be included.

If the manufacturer's signature isn't included, how would one know that it is signed?

** Section 4.2.15

   Identification of the type of manifest is always by a CoAP
   Content-Format integer [RFC7252].  If there is no CoAP identifier
   registered for the manifest format, one should be registered, perhaps
   in the experimental or first-come-first-served range.

If the manifest is always identified by the CoAP, per the first sentence, why "should" one be registered?  This would be a must.

** Section 4.2.15.

   When the [CoSWID] format is used, it MUST be a payload CoSWID, not an
   evidence CoSWID.

What makes something a "payload" vs. "evidence" CoSWID.

** Section 4.2.15

   A [SUIT.Manifest] may be used as a manifest.

What is the purpose of this explicit call out to SUIT.  Can't any manifest format with a Content-Format Identifier usable?

** Section 4.2.15.  (I'm no CDDL modeling expert) Why does the CDDL definition of manifest-format need cyclone-dx-* and spdx-*?  Couldn't one just say:

   $manifest-body-cbor /= text
   $manifest-body-json /= text

This would allow support for any text (JSON and XML) based manifest format?

** Section 4.2.17.  Is there any guidance to provide on how the "results-id" is generated?  How unique it is?  How entities need to coordinate on defining a common understanding it it?

** Section 4.2.18.  Typo. s/standaridized/standardized/

** Section 4.2.18.

     "CBOR":  The second array item must be some base64url-encoded CBOR
      that is a tag, typically a CWT or CBOR-encoded detached EAT bundle

This "must" needs to be a "MUST" to be consistent with the rest of the guidance in this section.

** Section 4.3.  Editorial. Why is Section 4.1 (eat_nonce) not in this section as they are providing meta-data about the token?

** Section 4.3.3.  intuse.  Does the WG expect this claim to be extended with additional values?  Should it be maintained with an IANA registry?

** Section 6.  Which parts of this section are normative vs. informative.  It looks like Section 6.3 is normative.  I can't tell with the rest since the rest of the sections (except in one place) don't use RFC2119 language.

** Section 7.2.1.  Editorial.

OLD
They are just text strings that contain a URI

NEW
They are just text strings that contain a URI conforming to the format defined in RFC3986

** Section 7.2.2.  Please find a reference for the "oid" format.

** Section 8.4

   EAT defines the nonce claim for replay protection and token
   freshness.  

Shouldn't this read "eat_nonce"?

** Section 9.3.  Should there be a normative "MUST" about providing a freshness mechanism?

** Section 9.4.  

   Since any COSE encryption will
   be removed by the receiving consumer, the communication of claim
   subsets to any downstream consumer should leverage a communication
   security protocol (e.g.  Transport Layer Security).

-- Per "Since any COSE encryption will ...", couldn't it also be JOSE too?

-- Should there be some mandatory equivalent made that the transport security properties should be at least as strong as the object security properties of the EAT?

** Section 9.4.

   However, assume the EAT of the previous example is hierarchical and
   each claim subset for a downstream consumer is created in the form of
   a nested EAT.  Then, Transport Layer Security between the receiving
   and downstream consumers is not strictly required.  Nevertheless,
   downstream consumers of a nested EAT should provide a nonce unique to
   the EAT they are consuming.

I don't follow how a hierarchical relation changes the required security.  Could this be clarified?

** Section 10.2.  Typo. s/preferrably/preferably/

** Section 10.5.  Please review https://www.rfc-editor.org/errata_search.php?eid=4954.  

-- The field named "Encoding" here should be called "Content Coding".  
-- Why is "binary" the right encoding for a json item.

** Section B.1. Typo. s/datadbase/database/

** Appendix E.  Who is the intended audience of this text?  New claims are going to into the JOSE and COSE registries which has it's own guidance to the DE.  There are no "EAT"-specific claims.

** E.5.  This section seems to make the case that is the opposite of E.2 and E.3 (which argued for generalization)

** F.1.2.  Typo. s/Siganture/Signature/

** F.2.  Good guidance is in this section.  Is there a reason it isn't in the Security Considerations section?

** Appendix G.  Should this be removed prior to publication?  If so, add text to the RFC Editor.

** References. [CycloneDX]

   [CycloneDX]
              "CycloneDX",
              <https://cyclonedx.org/specification/overview/>.

The IESG will push back at this being web link that could likely change to point to the latest version of the specification.  CycloneDX is versioned so please point to a particular version.  This looks like the a specific reference 

https://cyclonedx.org/docs/1.4/json/


Regards,
Roman