[Rats] EAT implementation (hackathon report)

[Thomas Fossati <[e-mail]>]

Hi all,

Sergei and I have been busy implementing the latest EAT spec at the hackathon.

We started from scratch and in three days we managed to produce a full
implementation [1] that is about 2.5KLOC, including 50+ accompanying
tests.

Overall, the impression is that the document is in pretty good shape
and can be implemented without too much ambiguity.

Here are a few random things we noticed in the process and that we
wanted to share with the EAT editors as well as the wider group:

1. It's not clear what is the story around the extensibility of single
claims?  E.g., if I wanted to expand the semantics of "Debug Disable"
or "Security Level" with my own local semantics, how would I do that?
This question popped when discussing whether the decoder should accept
values not currently listed and make them available to the user?

2. Typo: The "nonce" JSON label is missing from Section 4.3.1

3. The JSON story is nearly OK, except for two things: the Submods
claim where the JSON:CBOR equivalency is broken by allowing unbounded
int keys in CBOR that can't have an equivalent in JSON; the
StringOrURI type whose semantics can be preserved when transcoding.
The former could be solved by only allowing string labels.  The latter
by declaring we only deal in strings.

4. The CDDL for CWT claims is currently wrong: it’d allow only one CWT
claim at a time in the EAT map.  Scaling up a bit, we should probably
have a CDDL socket for EAT extensions in the top-level map (maybe
starting from CWT claims).

5. The CBOR interoperability section should have normative language
where needed and double check that there are no copy-pasted
requirements from other documents without an explicit ref -- e.g., the
stray "Duplicate map keys are not allowed." should have a ref to 7049.

6. Some typographic thoughts about Debug Disable claim.  The "disable"
in "Debug disable" is redundant; it'd be better renaming it as just
"Debug" or "Debug status". A bit more consistent wording wouldn’t hurt
too. e.g.:
* "Not disabled" => “enabled” -- this, combined with the above
suggestion, would move us from "debug disable not disabled" to a
simpler to digest "debug enabled" :-)
* "Permanent disable" => "disabled permanently"
* "Full permanent disable" => "disabled fully and permanently"

I think that's it; Sergei might have something more.

I can make Issues and PRs for all of the above if needed.

Thanks!

[1] https://github.com/veraison/eat

-- 
Thomas