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

"Smith, Ned" <> Thu, 20 September 2018 01:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7954B130DDD; Wed, 19 Sep 2018 18:20:53 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DaDJGvlr-v9A; Wed, 19 Sep 2018 18:20:51 -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 F0E90128B14; Wed, 19 Sep 2018 18:20:50 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Sep 2018 18:20:50 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos; i="5.53,396,1531810800"; d="scan'208,217"; a="74677125"
Received: from ([]) by with ESMTP; 19 Sep 2018 18:20:50 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 19 Sep 2018 18:20:49 -0700
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Wed, 19 Sep 2018 18:20:49 -0700
From: "Smith, Ned" <>
To: Denis <>, "" <>, "" <>
Thread-Topic: [EAT] Scope, Goals & Background for RATS
Thread-Index: AQHUTylnNI0FQ6zweUqGjmc9Pt9DhaT2T2wAgAISkoA=
Date: Thu, 20 Sep 2018 01:20:49 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D890BBF5E7344501B68F43CC36C80037intelcom_"
MIME-Version: 1.0
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: Thu, 20 Sep 2018 01:20:54 -0000

[nms] See my comments inline. - Ned.

On 9/18/18, 3:42 AM, "EAT on behalf of Denis" <<> on behalf of<>> wrote:

Hi Henk,

[nms]--- some text deleted ---

In the background section, the concept of a remote attestation is the following:

Remote Attestation is where the Attester conveys Attestation Evidence to a Verifier that compares it with Reference Values
(in order for it to be considered, for example, healthy). A Relying Party (or the Verifier acting as a Relying Party) appraises the verification result
to assess device trustworthiness and to manage security risk.
Since I could not grasp the concept of Attestation Evidence, I couldn't grasp the concept of a Remote Attestation which is based on it.
The goal is not simply to "assess device trustworthiness" but to make sure that some data exchange is really coming from a device
that has specific properties. Such properties are going beyond the protection, the non-export and the non-import of private keys.
[nms]The concept of associating security properties to data is described in more detail in We struggle with knowing how much terminology to include in a charter vs. save for a terminology draft. The basic idea is data inherits security properties of the environment (loosely defined term) that contains it. Sometimes people describe a communication path as a channel with ‘endpoints’. Lots of environments can be an ‘endpoint’ and endpoints have data-at-rest security properties. A goal of attestation should be to communicate the security properties of the endpoint that originated the data in the channel. Additionally, the channel has data-in-motion security properties. Often these properties are defined in terms of cryptography. A consideration for data-in-motion extends to the endpoint environment that protects the keys. These are subtly different concepts that could be conflated if our terminology is imprecise. In terms of the charter discussion, attestation of the endpoint environment that encompasses data-at-rest as well as endpoint environments that encompass keys used to protect data-in-motion are relevant to ‘remote attestation’.

I could not understand either the value of local attestations. IMO, the WG should only focus on remote attestations.
[nms] I believe the charter focus is only remote attestation. Local attestation is (should be) out of scope. Note: Since the charter distinguishes a focus on remote attestation it becomes necessary to acknowledge the existence of local attestation.
[nms]--- some text deleted ---
Explicit Attestation is where the Attestation Claims/Evidence is conveyed authentically (e.g. signed) by the Attester to the Verifier
where a root-of-trust enumerates the Attestation Claims/Evidence associated with an execution environment.
I would rephrase it in the following way:
Direct Attestation is when a verifier can be confident that some data originating from a client originates in practice from a secure device
that has specific functional and security properties.
[nms] It may be important to avoid overloading terminology too much as there already is a term “direct anonymous attestation” (DAA) that refers to a group signature scheme that is also an ISO standard.
[nms]--- some text deleted ---

Hi all,

we pushed an initial document to the RATS github in order to focus the discussion about remote attestation procedures a bit.

We included a background section to better highlight the meaning of the term "attestation" in general. Hence, there is a trade-off between clarity and conciseness, which is one of the things we would like to get feedback about.

Naturally, we are also very interested in feedback about the illustrated difference between explicit attestation and implicit attestation.

Viele Grüße,


EAT mailing list<>