Re: [EAT] Device Identity (was Re: [EXTERNAL] Re: [Rats] Attestation BoF charter updates?)

Henk Birkholz <> Sat, 20 October 2018 15:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03474130E69; Sat, 20 Oct 2018 08:44:00 -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 XsxIo4N9HXfA; Sat, 20 Oct 2018 08:43:57 -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 4F6B9130E63; Sat, 20 Oct 2018 08:43:55 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w9KFhoED009391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 20 Oct 2018 17:43:51 +0200
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 20 Oct 2018 17:43:44 +0200
Date: Sat, 20 Oct 2018 16:43:38 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----TRP3JB0JH0DXO4SLJG52JJ8RZUDE77"
Content-Transfer-Encoding: 7bit
To: Laurence Lundblade <>
CC: "" <>, Guy Fedorkow <>, Hannes Tschofenig <>, "Smith, Ned" <>, "Jeremy O'Donoghue" <>, "" <>, Denis <>
From: Henk Birkholz <>
Message-ID: <>
X-Originating-IP: []
Archived-At: <>
Subject: Re: [EAT] Device Identity (was Re: [EXTERNAL] Re: [Rats] Attestation BoF charter updates?)
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: Sat, 20 Oct 2018 15:44:00 -0000

Hello Laurence,

what I understood now, I think, is that the processes that will eventually make use of EATs - "in the bigger picture" - are intended to be based on more than proof-of-possession.
The EAT that is the signed claim set is relying on the "assumption that the device manufacturer will only put attestation keys in devices that are configured correctly".

And that is exactly what I meant. The key material deployed on the thing has meaning: if it is there, you trust the assumption that the thing is configured correctly.

Do we agree on this? :-)

The reoccurring reference to TCG seems to exclude other more thorough approaches on how to conduct remote integrity verification a bit, I think. I am carefully highlighting this, because the reasoning behind an IETF WG is the demand for network protocols that are able to consolidate the different "inbox-api" and "out-of-band" concepts used in various domains.

Viele Grüße,


On October 20, 2018 4:21:52 PM GMT+01:00, Laurence Lundblade <> wrote:
>> On Oct 20, 2018, at 8:26 PM, Henk Birkholz
><> wrote:
>> Hello Laurence,
>>  And I am perplexed how you think I was implying that EAT or CoID are
>insecure. How did I make the impression to have suggested that?
>You have characterized EAT as only proof-of-possesion. It is not.
>> Wrt the "verification keys" I am not so sure, what the diagram means
>by that. With an asymmetric key-pair these would probably be public
>keys to check the signature by (I assume)?
>It is an open-ended range of things:
>An ECDAA interaction with service (Maybe like Intel’s)
>A verification request of an Android Attestation from a Google Service
>An IEEE-802.1AR CA and Sub-CAs (mostly standard X.509)
>A public key fetch based on any reasonable / useful key ID (e.g.
>Subject Key ID)
>A submission of the EAT token signed by a symmetric key to a service
>that verifies it (and rather carefully protects the private
>verification keys with high quality HSMs)
>A redirect through a privacy CA
>Some custom manufacturer defined scheme
>I strongly believe this flexibility is necessary for real deployments
>especially for the high investment already made by platform and chip
>There is an assumption that the device manufacturer will only put
>attestation keys in devices that are configured correctly. Typically
>the attestation key will only be usable to sign attestation if the
>device booted code that was verified, debug was turned off and such. (I
>know TCG does this in a more elaborate thorough way, and that is good
>and well and can be put to use with EAT for appropriate use cases). 

Sent from my Android device with K-9 Mail. Please excuse my brevity.