Re: [Rats] EAT implementation (hackathon report)

Laurence Lundblade <> Sat, 14 November 2020 19:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A63F13A1276 for <>; Sat, 14 Nov 2020 11:17:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GQuMq-PD2J-p for <>; Sat, 14 Nov 2020 11:17:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 303FE3A1275 for <>; Sat, 14 Nov 2020 11:17:18 -0800 (PST)
Received: from [] ([]) by :SMTPAUTH: with ESMTPA id e12zkUeSIa9C9e12zkoXmp; Sat, 14 Nov 2020 12:17:17 -0700
X-CMAE-Analysis: v=2.4 cv=MtWXV0We c=1 sm=1 tr=0 ts=5fb02d3d a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=pGLkceISAAAA:8 a=0XtbOteLAAAA:20 a=FCgtu_yeINVdqy4v9s8A:9 a=QEXdDO2ut3YA:10 a=5LK7L2lp7N0EAjUIVDsA:9 a=TvYIIWM2C3wvnf1T:21 a=_W_S_7VecoQA:10
From: Laurence Lundblade <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B457441A-D3B1-40AF-AE73-9937D8E3B47F"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Date: Sat, 14 Nov 2020 11:17:17 -0800
In-Reply-To: <>
To: Thomas Fossati <>
References: <>
X-Mailer: Apple Mail (2.3445.104.17)
X-CMAE-Envelope: MS4xfHBKbl0+0h9upNH/mAAEZk9mvuMa8t5VaKTHIyygFbh4pYDFnLg10bj5T6eAs1CVk0T4mJ9XK1micguZZZ3lWIerGTD1ibelz9NwLvStb/T1xFQ4UIPt rSYdWN/BeY2p0wwVodaBVYL/7ii2lRqANJR9NhubYFEvQlqOwM+FfibEY30kvERGWWFgTP28jrUv9o7ZhRw4OC27v5WaFjjq6oKMUSn8F20FJMRENCkZGg1/ iaQ9RnLRSrB141LgZq/xoA==
Archived-At: <>
Subject: Re: [Rats] EAT implementation (hackathon report)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 14 Nov 2020 19:17:20 -0000

> On Nov 12, 2020, at 9:16 AM, Thomas Fossati <> wrote:
> 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?

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

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

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

Pushed a fix for StringOrURI to master.

Made submodule names string only as part of this PR <>. 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.