Re: [Rats] Robert Wilton's Discuss on draft-ietf-rats-eat-21: (with DISCUSS and COMMENT)

["lgl island-resort.com" <[e-mail]>]

Hi Rob,

Thanks of the review. Comments below

LL


On Sep 7, 2023, at 6:09 AM, Robert Wilton via Datatracker <[e-mail]> wrote:

----------------------------------------------------------------------
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,
             <https://datatracker.ietf.org/doc/html/draft-ietf-rats-
             architecture-22>.

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

I’m fine with it either way. Maybe others could chime in with opinions.

I’ve read RFC 3967 and friends, but am still not sure if I have to do anything in the EAT doc other than change the type of reference if the consensus is for normative.


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

A few reasons I would give for JSON support:
- JSON is much more widely used and understood than CBOR so we’ll get more adoption
- EAT is good for attestation results (in addition to evidence) which is often B-to-B / server-to-server where JSON and JWT is widely used
- Backend systems that operate on attestation evidence/results will often prefer JSON
- It’s good that we went to all the trouble now to know how to embed JSON tokens in CBOR tokens and vice versa

It would be a huge upheaval to change this now. Probably many that have come to expect JSON support over the years of work here would be unhappy.


(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.

We could re order so swname is not next to hw-related claims. Move it down by manifests. Wouldn’t be as surprising then :-)

I’m half serious because it is more related to manifests.

Most of the answer here is that swname has a more formal alternative in the manifests claim and the HW identifiers don’t. The swname claim exists because the manifests claim is complicated and requires use of an external format not defined in EAT (e.g., CoSWID).


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

Thx. https://github.com/ietf-rats-wg/eat/pull/409


(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.

I have looked over uuidrev and don’t think it changes the design or appendix B.


(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 ...

Have clarified that appendix B.1 is only for type 1 UEIDs. The statement in B.2 is for type 2 UEIDs

https://github.com/ietf-rats-wg/eat/pull/408<https://github.com/ietf-rats-wg/eat/pull/40>