Re: [Rats] Response to Eliot's major issues with EAT

Laurence Lundblade <> Thu, 30 June 2022 16:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7CCFFC13A236 for <>; Thu, 30 Jun 2022 09:25:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.927
X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id USnhH7EQ5Rcj for <>; Thu, 30 Jun 2022 09:25:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6A4D1C13CDB5 for <>; Thu, 30 Jun 2022 09:25:23 -0700 (PDT)
Received: from [] ([]) by :SMTPAUTH: with ESMTPA id 6wymohAw1AGId6wynohOR6; Thu, 30 Jun 2022 09:25:22 -0700
X-CMAE-Analysis: v=2.4 cv=B5B8bMhM c=1 sm=1 tr=0 ts=62bdce72 a=qS/Wyu6Nw1Yro6yF1S+Djg==:117 a=qS/Wyu6Nw1Yro6yF1S+Djg==:17 a=NEAV23lmAAAA:8 a=pGLkceISAAAA:8 a=-q2cEHLMAIq8d-XnDeYA:9 a=QEXdDO2ut3YA:10 a=XOxtU8gkedozhDp_:21 a=_W_S_7VecoQA:10
From: Laurence Lundblade <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E6B8E85F-F45A-42E7-B545-0A5DF46C8C86"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
Date: Thu, 30 Jun 2022 09:25:19 -0700
In-Reply-To: <>
Cc: Eliot Lear <>, rats <>
To: Kathleen Moriarty <>
References: <> <>
X-Mailer: Apple Mail (2.3445.104.21)
X-CMAE-Envelope: MS4xfEt8Qko94IrT185YVEF7kpYvOBUI64S5nOFZnYeFWE/zx9nNggwKc1mHEoO7OGCP3TrWlaylgV7o6XUKTkBf9gn2mUOr6F+3ckFqAZo1TXwNrC/k3NM4 vYkpvPNNix/WJz/HpR1HVhb98NFZp07GJWbQnS0lB1WDB0iSzXnW0TIZwNl8dR1dCx+nArySwqz0DHvR49yeZcUDbzEhlr0W9h2ZWNFyoz11Cnt0cglP6iao 0vRN3RL+H5HHAm+DQqwp4g==
Archived-At: <>
Subject: Re: [Rats] Response to Eliot's major issues with EAT
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Remote ATtestation procedureS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 Jun 2022 16:25:25 -0000

Hi Kathleen,

These recent PRs improve profiles significantly and resulted from Eliot’s (and MCR’s) comments:
Improve introduction to profiles <>
Make profile issues more prescriptive <>
Add standard constrained device profile <>
Clarify how a profile can re-define an EAT claim <>
Remove most of section 8.3 on CBOR Serialization, redundant with profiles <>
Maybe frame it up this way — EAT is kind of the messenger here.  EAT is not the source of these interoperability characteristics of CWT/JWT, COSE and CBOR. They existed before EAT came along. You can see this in the sections in the JWT, COSE and CBOR documents that talk about implementation variability. They aren’t so forward with the word “interoperability” as I was in the EAT section. Agreed, I could have chosen better words in EAT (wording improved improved intro to profiles PR), but please don’t shoot me for that. 

A  another reason for not shooting is that beyond the message, EAT gives a solution — profiles. Seems like there’s pretty good support for the solution to me.  I’m certainly open to improving profiles as I hope the above PR’s show.

Plus, I’ve made a PR <> that adds SPDX and CycloneX as manifest formats. Comments please. This is not an area of expertise for me.

A few more answers below. 


> On Jun 28, 2022, at 4:34 AM, Kathleen Moriarty <> wrote:
> Good morning.  I read through the response and have some comments. 
> ...
>> Section 4.1:
>>    The nonce MUST have 64 bits of entropy as fewer bits are unlikely to
>>    be secure.  A maximum nonce size is set to limit the memory required
>>    for an implementation.
>> There are two sides to this equation: the generator of the nonce and
>> the consumer.  How is the generator supposed to know how much memory
>> the consumer has?
> The memory use of the nonce for the consumer is capped by the specification of a maximum size. That maximum is 74 bytes per nonce which is a relatively small amount that any implementation should be able to afford.
> I think it is right to cap the size of the nonce and a few other critical and common claims like UEID, but obviously we can’t cap them all.
> Was there any agreement on this? I just see your response? 

There was no discussion on this. There is only my response.

The way it looks to me is that the document addressed the issue clearly, but Eliot missed the text that addressed it when he commented (we all miss things). There is a clear upper bound specified in the the document (74 bytes for JSON, 64 bytes for CBOR) that will limit the amount memory the consumer needs for the nonce.

>> Section 4.2.1:
>>    UEIDs are variable length.  All implementations MUST be able to
>>    receive UEIDs that are 33 bytes long (1 type byte and 256 bits).  No
>>    UEID longer than 33 bytes SHOULD be sent.
>> 256/8 = 8.  8+1 = 9.  I don't understand the parenthetical.
> Clarifications here <>. No more need to do math.
> What update was made in the draft? What explains the discrepancy in the byte length? The link didn't explain it or the link isn't the right one anymore.

It turns out Eliot’s math was wrong here. 258 / 8 = 32, not 8 so there was nothing technically wrong with the document.

Even so, I made some wording improvements in the document and took out the text “(1 type byte and 256 bits)”, the reason for the math exercise. I think the new text is more clear.