Re: [EAT] [EXTERNAL] Re: [Rats] Real EAT implementations

Jeremy O'Donoghue <> Sat, 06 October 2018 22:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF3AF1286D9; Sat, 6 Oct 2018 15:07:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ng_v-3TTKHZ3; Sat, 6 Oct 2018 15:07:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4AC5E127AC2; Sat, 6 Oct 2018 15:07:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1538863674; x=1570399674; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2HXX/m4gKUUK/Un2xq51ypaCX7/Xb5dwpQ4KcOYqFmw=; b=UqmzqMrD/gILnWCBVBlpE9yYhFqTShQ2zCwap1vjQESwjb9Y0sv0n9HJ 0oOrrM0z2TtdXWJ8VMyX+RuBibyFD3LhP4h6mZOYdousAme1t5tmeWFaR 7EaD/4N3pdbB3Xf3k4wBWJVszhNO9OXAOdgp8inA65I9BDcTU4wVbGyzT 4=;
X-IronPort-AV: E=Sophos;i="5.54,350,1534802400"; d="scan'208,217";a="1294872"
Received: from ([]) by with ESMTP; 07 Oct 2018 00:07:09 +0200
X-IronPort-AV: E=McAfee;i="5900,7806,9038"; a="5812390"
Received: from ([]) by with ESMTP/TLS/AES256-SHA; 07 Oct 2018 00:07:09 +0200
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1365.1; Sun, 7 Oct 2018 00:06:55 +0200
Received: from ([]) by ([]) with mapi id 15.00.1365.000; Sun, 7 Oct 2018 00:06:55 +0200
From: Jeremy O'Donoghue <>
To: Michael Richardson <>
CC: "" <>, "" <>
Thread-Topic: [EXTERNAL] Re: [EAT] [Rats] Real EAT implementations
Thread-Index: AQHUXZpWiOFcYSwDEEiK9/4SZiResKUSlQqA
Date: Sat, 6 Oct 2018 22:06:55 +0000
Message-ID: <>
References: <> <30469.1538847042@localhost>
In-Reply-To: <30469.1538847042@localhost>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-mailer: Apple Mail (2.3445.9.1)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_0BEAA9FA31F2442ABD6329291E658DE6qtiqualcommcom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [EAT] [EXTERNAL] Re: [Rats] Real EAT implementations
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, 06 Oct 2018 22:07:57 -0000

On 6 Oct 2018, at 18:30, Michael Richardson <<>> wrote:

Laurence Lundblade <<>> wrote:
I believe one of the area directors asked who’s going to implement
these attestation schemes we standardize. One answer is Qualcomm’s
already commercialized precursor implementation of EAT which is
described very briefly in official marketing material on Qualcomm’s
web site as “Hardware Token”.

I see this as evidence:
 1) the market doesn't need/want a standard
 2) Qualcomm isn't going to implement our standard, they already have their own.

Now that could be trivially be refuted if we saw clear participation from
qualcomm, but I haven't seen it yet.  But, maybe I missed it.

OK, so I'll bite on this... in two separate capacities: one based on my employer and the second as Chair of the Trusted Platform Services Committee at GlobalPlatform.

You'll notice that all four names on the EAT draft are or were Qualcomm employees. EAT is definitely of interest to us.

EAT is under serious consideration as the basis of an attestation format for GlobalPlatform Secure Components (i.e. TEE and Secure Element). We see benefit in having the IETF standardise the more generic aspects of an attestation format around EAT with the GlobalPlatform specifics being addressed by GlobalPlatform.

I'm afraid I'm not very familiar with the arcana of chartering at IETF, so much recent discussion has perhaps not registered with me as strongly as it could have.

Jeremy O’Donoghue
Engineer, Principal/Manager, Qualcomm Inc.