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

Laurence Lundblade <> Fri, 21 September 2018 17:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D1387130E92 for <>; Fri, 21 Sep 2018 10:01:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WavpHS_ErD4q for <>; Fri, 21 Sep 2018 10:01:36 -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 6CF84130E98 for <>; Fri, 21 Sep 2018 10:01:36 -0700 (PDT)
Received: from [] ([]) by :SMTPAUTH: with ESMTPSA id 3OoAgLHMT0PdY3OoBg2Tsa; Fri, 21 Sep 2018 10:01:35 -0700
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
From: Laurence Lundblade <>
In-Reply-To: <>
Date: Fri, 21 Sep 2018 10:01:34 -0700
Cc: "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Henk Birkholz <>
X-Mailer: Apple Mail (2.3445.8.2)
X-CMAE-Envelope: MS4wfPICXn6+LdauxqLxXdVeso/iqyEie6PHuKoxgSOFwluLiBcfaG6Yd0vdDcDwVTG+OeQbLZ3SUe0o10VsUrQnWmv4CPDyuAiv6Cu0l0ECFslVg2+SiDIy VmRAYI+jLV4kd3qZlYZ6EFwbh/4FHYqZhKQHK4tJVNIEO1qD4vmzOEZEVRFjaCeISRuGExX3q3AYMj3tYAC2QoCt8KcBNc+jD0ppUCLPETVvmNxBQpUHyppl
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 17:01:39 -0000

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. 


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