Re: [EAT] Scope, Goals & Background for RATS

Henk Birkholz <> Fri, 21 September 2018 21:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D08F1286E3; Fri, 21 Sep 2018 14:06:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MAyj4FO9-6tW; Fri, 21 Sep 2018 14:06:38 -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 62BC712785F; Fri, 21 Sep 2018 14:06:36 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w8LL6WIJ016037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Sep 2018 23:06:33 +0200
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 21 Sep 2018 23:06:27 +0200
To: Laurence Lundblade <>
CC: "" <>, "" <>
References: <> <> <> <>
From: Henk Birkholz <>
Message-ID: <>
Date: Fri, 21 Sep 2018 23:06:26 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: []
Archived-At: <>
Subject: Re: [EAT] Scope, Goals & Background for RATS
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EAT - Entity Attestation Token <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Sep 2018 21:06:41 -0000

Hello Laurence,

splintering emerging work on attestation in the IETF at the very 
beginning does not seem to be very productive to me, too. I 
wholeheartedly agree with that notion.

I hear your assessment that EAT and RATS have distinct goals and -  as 
our slowly improving convergence of approaches shows - that is true to 
some extend, I think. But I also think that there is significant overlap 
and creating synergy via this overlap, while also creating a shared 
consistent terminology, is vital and I'd optimistically consider that 

I really am interested in the deployment scenarios that you envision for 
EAT. I am rather certain that we could identify more overlap there. The 
RATS charter covers deployment only in very specific detail at the 
moment. Some scoping had to be done to create a tangible set of 
realistic goals for chartering. That said, deployment is also an 
important aspect for RATS, just not at this very beginning.

I am also rather certain that EAT can be used in a lot of places. I 
really like the approach, as I am a proponent of CWT. I also was under 
the impression that EAT does not exclude the option to be rooted in TPM? 
While that might only be a technical detail, I bring that up because the 
"non-exclusiveness" of both EAT and RATS wrt to specific hardware 
solutions was an overlap. But maybe I missed something obvious here.

In summary, creating a common "middle ground" and working in concert in 
these shared domains (manifested in drafts) seems to be the optimal way 
to move forward, I think.

My only actual concern remains to be the creation of a shorter charter 
:) Merging goals does not really sound like making it shorter - well, at 
least initially.

Viele Grüße,


On 09/21/2018 07:01 PM, Laurence Lundblade wrote:
> RATS folks: Henk, Ned, Monty and Eric,
> EAT has deployment scenarios and goals that are distinct from RATS. They don’t need new protocols in the same way as that RATS does. They will not be rooted in TCG and TPM work. There is precedence in the industry for these use as can be seen in FIDO and Android Keystore Attestation. EAT can not just be a subordinate part of RATS as you seem to imply below.
> Even if our deployment goals and use cases are not the same, I would think we can have separate documents where we need to and do the work in one WG.
> I think it would be bad to have two attestation working groups in the IETF, one for EAT and one for RATS.  Thus, I think the charter of this WG must explicitly include the EAT use cases and goals.
> LL
>> On Sep 21, 2018, at 9:24 AM, Henk Birkholz <> wrote:
>> Hello Laurence,
>> please find replies and comments in-line:
>> On 09/20/2018 10:18 PM, Laurence Lundblade wrote:
>>> It’s a bit buried, but I see you do intend that this include the EAT work. Thus the work would not be TPM/TCG centric. It would include use cases like FIDO and Android Keystore attestation that are often based on TrustZone. It could also include EPID-related use cases. Please confirm.
>> I am not sure, if I am the authority to confirm this, as kickstarting RATS is a group effort. What I can do is to agree with the statement that RATS is abstracting from specific hardware solutions that provide, for example trust anchors and shielded locations (which keystores are a subset of, I think), or restrict secret key access (protection of execution, I think) based on system status (or more generic - system health).
>> Conveyance of Attestation Claims is a big part of implicit attestation and the comparison of (amongst other information) claims wrt to appraisal of Attestation Evidence in explicit attestation. As EAT provides a data format to express these claim sets in a state-of-the art representation (and, if signed, via a state-of-the-art COSE envelope) they are compose a perfect option to address the data model part of conveyance.