Re: [Rats] I-D Action: draft-ietf-rats-eat-15.txt

[Laurence Lundblade <[e-mail]>]

Thank you for the quick turn around review!

Comments below.


> On Oct 2, 2022, at 4:17 AM, Michael Richardson <[e-mail]> wrote:
> 
> 
> [e-mail] wrote:
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-rats-eat/
> 
>> There is also an HTML version available at:
>> https://www.ietf.org/archive/id/draft-ietf-rats-eat-15.html
> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-rats-eat-15
> 
> I wish I could read the diff.
> You did not fix the too-long lines.
> 
> I edited -14 and -15 to truncate the long lines in the appendix, and put that
> onto github (since iddiff has a limited set of places it will read from), and
> readers can try:
> 
> https://author-tools.ietf.org/diff?url_1=https://raw.githubusercontent.com/mcr/eat/eat-diff-short/draft-ietf-rats-eat-14.txt&url_2=https://raw.githubusercontent.com/mcr/eat/eat-diff-short/draft-ietf-rats-eat-15.txt
> 
> iddiff is not yet as good rfcdiff, and generates some additional diffs around
> page breaks and the like.

I can see the diff between 14 and 15 is not good now and will fix it for 16 (aiming for London cutoff date).

I try to work to priority and didn’t see the long lines as a priority because the diff between draft-13 and -14  <https://www.ietf.org/rfcdiff?url1=draft-ietf-rats-eat-14&url2=draft-ietf-rats-eat-13&difftype=--html>seems OK and only you had mentioned it. That is, I did not ignore your previous comment. When I checked it didn’t seem like a general problem.


> 
> Some comments:
> 
> 1) you've changed the section names of the claims:
> 
> Universal Entity ID Claim (ueid) ->  ueid (Universal Entity ID) Claim
> I see why this might be a good idea, but it sure isn't pretty.
> I will think on this.

It is to align with the way CWT and JWT are authored.


> 
> 4)"This document registers no media or content types for the
>   identification of the type of EAT, its serialization format or
>   security envelope.  That is left for a follow-on document."
> 
> I'm okay with this, but maybe to say,
>    That is left for to follow-on documents, or may be defined by
>    by documents that define EAT Profiles.

Seems like a good improvement.


> 
> 5) Can Detached EAT Bundles contain a mix of CWT and JWT?
>   Up in the introduction, it seems to imply this, but I think section 5 says no.

The intent is that you can have these two:
- CBOR-encoded bundle that carries CBOR-encoded detached Claims-Sets
- JSON-encoded bundle that carries JSON-encoded detached Claims-Sets
but not these
- CBOR-encoded bundle that carries JSON-encoded detached Claims-Sets
- CBOR-encoded bundle that carries both CBOR-encoded and JSON-encoded detached Claims-Sets
- JSON-encoded bundle that carries CBOR-encoded detached Claims-Sets
- JSON-encoded bundle that carries JSON-encoded CBOR-encoded detached Claims-Sets

In theory we could improve the design of of bundles to allow all of these, but it would add complexity because we’d need to include a type so that JSON-encoded bundles could know the difference between base64’d JSON-encoded Claims-Set and a base64’d CBOR-encoded Claims-Set.

There is a PR here with some clarification: https://github.com/ietf-rats-wg/eat/pull/318



> 
> 6) "Each claim defined in this document is added to the $$Claims-Set-
>   Claims socket group. "
> 
> The term "socket group" is a CDDL-ism.  I know what it means, but it might be
> confusing to some (pointy haired manager) who don't know what CDDL is.
> It might be worth adding to the terminology section.  I'm not sure here.

Forked off a separate discussion for this.


> 
> 7) 4.2.13.  bootseed (Boot Seed) Claim
> 
>   The "bootseed" claim contains a value created at system boot time
>   that allows differentiation of attestation reports from different
>   boot sessions of a particular entity (e.g., a certain UEID).
> 
>   This value is usually public.  It is not a secret and MUST NOT be
>   used for any purpose that a secret seed is needed, such as seeding a
>   random number generator.
> 
> I guess that the second paragraph is needed because the word "seed" might
> confuse people into thinking it has something to do with seeding PRNGs.
> Maybe the problem is the name of the claim.
> Maybe we can come up with a different name for the claim instead?
> Maybe bootnonce, or bootinstance or ??
> 
> If I have bootcount, and I have a per-device identifier (UEID...),
> can I use UEID as a key to CBC encrypt bootcount to make bootseed?

Yes. Or a hash.

The implementation I imagined was calling the RNG once at boot and saving it in the bootseed file. Then read the file when generating the claim. That seemed a bit close to seeding a PRNG, and also the name is similar.

I like bootinstance. Maybe bootoccurance. Not bootnonce because of confusion with other nonces.

For a cleaner claim definition, the second paragraph could move to security considerations. Or be removed.

Pretty open to changes here.


> 
> 8) DLOAS: "This claim is typically issued by a verifier, not an attester."
> would it be worth splitting 4.2 up into two or three sections?
> * Claims from Attesters or Verifiers
> * Claims from Attesters
> * Claims from Verifiers
> ?
> (Also measres claim)

In my view all claims are authored in a way neutral as to whether they occur in results or evidence. Section 1.3.1 explains what needs to be known about this.

Perhaps the text that says this is typically issued by a verifier should be removed. It is an intention that claims be authored neutral this way.


> 
> 9) section 4.2.18.1.2.2.  Six levels of subsection tells me that maybe
> something is wrong.
> 
> Probably Submodules claim can go into claims area, but then forward reference
> an entire Submodules *SECTION*

Yeah. While I think the design for submods is good, the text describing it could be improved a lot. It’s on the list for -16 and some PRs have started in on this.

LL