Re: [Rats] EAT implementation (hackathon report)

Thomas Fossati <> Sat, 14 November 2020 20:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5AB043A12B3 for <>; Sat, 14 Nov 2020 12:29:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PuXisr4gL9cy for <>; Sat, 14 Nov 2020 12:29:10 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 91CF03A12B1 for <>; Sat, 14 Nov 2020 12:29:10 -0800 (PST)
Received: by with SMTP id s9so15058915ljo.11 for <>; Sat, 14 Nov 2020 12:29:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=gZdTMcKDgnHFBtQcATr+yNYuSX+E8V5svQ1yd3/n0HQ=; b=fkMVJkLRu91iuhjn5iP25fuuf+3MWkUnHCG76PvI2HoVChZZ1pLxRIEFg33nqwzPWA 6i+X6mFFLZRyL6Etyua0+6Nb9TCzTzd7YKEvChYsoGGFG/DcwYPcWcI0xCSCBhP/9gPG l87sqJALolJr9+hSTwaYagFcGzvMnbpy7rZ0X79bjqXG8OJeGKP9vGHZN089HdJ4So5t cHdpFk4myb/4L6EBYmxUt+2/TCo783CAB4zM4B3xUb3hbdLRn2Ft5JV+n2QzNfK1wCrX DiZqSJQfgZkgNqJ2hJRB53PklsS22ePCXV1X9VsEMQCOahaMCLtzU7maYiU/0op2rIY4 zAdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=gZdTMcKDgnHFBtQcATr+yNYuSX+E8V5svQ1yd3/n0HQ=; b=m77MS5V2q23gG9QleZ1b15Cd2/+vGAQarp4Ixxw92JyhFO/+ugX/ylyxHEh6622hCV 5iagL6XdJpqL51YDcqHPp3AzyotmwSxzaZ/mmv2/jg5EthqzDqq4IebgcPusDMF7tOGS zyAirYK2aB4rmF5imEceir/9oB1N+F/yMxSZZv9WN0hI2AuK4XLc8toff9ZSVnl8lCbM iFkwuXktVjFiwv9Ry8TFjfgJmbCYbxLSNzwHAnF605jiM5WxMFV2PcLmpbbIonSzqgIK 0FHlfVkohyOfhamaBtwexPX9b9K+uCvRX7yGuXk90Im6M6IIXNDAxuJsRfD1u4WUEFwn hQhQ==
X-Gm-Message-State: AOAM533IPyz9lIN3KhpsWlwUdClzETOW9ZcLfz/rSOyz9ekcNc3dMeHK Jx6x6TltDC3/ucNxQYWFbs3ZiMsT/XfU/0qW3nI=
X-Google-Smtp-Source: ABdhPJyJ/2GIT3t5JBtInm15cfx1PLgWel0ZuRifKmiQttMQD1Xe1nDE0CBh0My5lhkLDcL8QwiNBZtrh9hreZdtUM4=
X-Received: by 2002:a2e:9244:: with SMTP id v4mr3332848ljg.438.1605385748568; Sat, 14 Nov 2020 12:29:08 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Thomas Fossati <>
Date: Sat, 14 Nov 2020 20:28:57 +0000
Message-ID: <>
To: Laurence Lundblade <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 20:29:12 -0000

Hi Laurence, Nancy, Kathleen and Michael,

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

including Laurence's replies below.


On Sat, Nov 14, 2020 at 7:17 PM Laurence Lundblade
<> wrote:
> 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.
> LL