Subject: [Rats] EAT implementation (hackathon report)

From: Thomas Fossati <[email-masked]>
Date: Thu, 12 Nov 2020 17:16:47 +0000

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 12 Nov 2020 16:58:21 -0500

Amazing Thomas!

    > values not currently listed and make them available to the user?

At the least, it should be tolerant of them.
It should make them available, I think.

    > stray "Duplicate map keys are not allowed." should have a ref to 7049.

!Yes.

    > "Debug" or "Debug status". A bit more consistent wording wouldn’t hurt

That makes sense.

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

Do you have examples you might want to put into to the document?

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 13 Nov 2020 15:40:40 -0500

Thank you, Thomas and Sergei!  This is really great work and good to see
your thoughts on the readiness of the document from an implementation
standpoint.

Best regards,
Kathleen

On Thu, Nov 12, 2020 at 4:58 PM Michael Richardson <[email-masked]>
wrote:

> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

-- 

Best regards,
Kathleen

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Fri, 13 Nov 2020 20:57:56 +0000

Indeed, this is great progress Thomas and Sergei!

It would be great if you can contribute examples....and also would be good for you to input the issues and comments in the github to make sure they are addressed.

Best, Nancy

On 11/12/20, 1:58 PM, "RATS on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

    Amazing Thomas!

    

    !Yes.

    That makes sense.

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 14 Nov 2020 11:17:17 -0800

> On Nov 12, 2020, at 9:16 AM, Thomas Fossati <[email-masked]> wrote:
> 
> Hi all,
> 

I don’t think these should be extensible. You can’t make up your own corporate bond rating category or restaurant hygene rating category and such. If that is allowed the scheme becomes much less useful. 

I’ve added text for that in this PR <https://github.com/ietf-rats-wg/eat/pull/73>. It says that when you can’t live with the defined security level schema, omit the claim, make up your own claim or do both.

Also, see this old but unresolved discussion <https://github.com/ietf-rats-wg/eat/issues/4> on security level. One thing nice about a very simple three-level scheme is that it becomes clear this is a very rough top-level characterization only.

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

The JWT nonce was already in the IANA registry for JWT. I added CDDL for it and note that some of the CDDL in EAT is for things defined elsewhere before there was CDDL.  See this PR <https://github.com/ietf-rats-wg/eat/pull/72>.

> by declaring we only deal in strings.

Pushed a fix for StringOrURI to master.

Made submodule names string only as part of this PR <https://github.com/ietf-rats-wg/eat/pull/67>. Was thinking that they should only be strings myself. 

No progress on the others yet. Would appreciate issues being opened.

Really appreciate the work and the validation of the application of CDDL to JSON! Thanks for the good comments.

LL

---

From: Thomas Fossati <[email-masked]>
Date: Sat, 14 Nov 2020 20:28:57 +0000

Hi Laurence, Nancy, Kathleen and Michael,

(Apologies for top-posting.)  Following Nancy's advice, I've opened
the following issues:

https://github.com/ietf-rats-wg/eat/issues/74
https://github.com/ietf-rats-wg/eat/issues/75
https://github.com/ietf-rats-wg/eat/issues/76
https://github.com/ietf-rats-wg/eat/issues/77
https://github.com/ietf-rats-wg/eat/issues/78
https://github.com/ietf-rats-wg/eat/issues/79

including Laurence's replies below.

cheers!

On Sat, Nov 14, 2020 at 7:17 PM Laurence Lundblade
<[email-masked]> wrote:
> I’ve added text for that in this PR. It says that when you can’t live with the defined security level schema, omit the claim, make up your own claim or do both.
>
> Also, see this old but unresolved discussion on security level. One thing nice about a very simple three-level scheme is that it becomes clear this is a very rough top-level characterization only.
>
>
>
> The JWT nonce was already in the IANA registry for JWT. I added CDDL for it and note that some of the CDDL in EAT is for things defined elsewhere before there was CDDL.  See this PR.
>
>
>
> Made submodule names string only as part of this PR. Was thinking that they should only be strings myself.
>
>

-- 
Thomas

---

From: Thomas Fossati <[email-masked]>
Date: Sun, 15 Nov 2020 00:50:12 +0000

Hi Nancy,

On Fri, Nov 13, 2020 at 8:58 PM Nancy Cam-Winget (ncamwing)
<[email-masked]> wrote:
> It would be great if you can contribute examples....

Do you mean code examples?  If so, there's nothing at the moment, but
we are going to work on expanding the documentation [1] to contain
code snippets to show how to use the API.
Or do you mean examples of output produced by the library?
Or something else?

cheers, t

[1] https://pkg.go.dev/github.com/veraison/eat
-- 
Thomas

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Tue, 17 Nov 2020 06:13:34 +0000

Hi Thomas,
No need for code, but the EAT draft only has two simple examples, so having something that you have actually tried and may be good; so more of the output produced from your library.

Best, Nancy

On 11/14/20, 4:51 PM, "Thomas Fossati" <[email-masked]> wrote:

    Hi Nancy,

    
    cheers, t

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 17 Nov 2020 11:39:17 +0000

Hi Nancy, thanks for the clarification!

On Tue, Nov 17, 2020 at 6:13 AM Nancy Cam-Winget (ncamwing)
<[email-masked]> wrote:
> No need for code, but the EAT draft only has two simple examples,
> so having something that you have actually tried and may be good;
> so more of the output produced from your library.

I can surely provide more examples if needed using our library, but my
suggestion would be to use the CBOR diag-based assembly and
verification [1] instead, which is now built in the EAT draft
pipeline.

cheers!

[1] https://github.com/ietf-rats-wg/eat/pull/69

-- 
Thomas