Re: [EAT] Implicit vs Explicit Attestation (was Re: Scope, Goals & Background for RATS)

Laurence Lundblade <> Mon, 24 September 2018 22:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4E859131127 for <>; Mon, 24 Sep 2018 15:47:03 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id su6rZLD751H4 for <>; Mon, 24 Sep 2018 15:46:59 -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 22C2E13115B for <>; Mon, 24 Sep 2018 15:46:59 -0700 (PDT)
Received: from [] ([]) by :SMTPAUTH: with ESMTPSA id 4Zd3gkOvk3klB4Zd4gicgK; Mon, 24 Sep 2018 15:46:58 -0700
From: Laurence Lundblade <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2FABFB15-7146-4B6D-9EC8-D56C2EDAA826"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Date: Mon, 24 Sep 2018 15:46:57 -0700
In-Reply-To: <>
Cc:, Denis <>,
To: Henk Birkholz <>
References: <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.8.2)
X-CMAE-Envelope: MS4wfAeNfIjO8au6x1p2aqlzqcOvuFoMifO3tI4OOJuMwP3WaUf+VdAVsVpCisESNDjE/dD61q0sXQP/907EbszDx5xJTghAn4fbvUB+3acZq5ACmYg+fx0d 03konL2EWfbfKT+uBSFgchPV3ToPxQBk0ZPARkgZqmoMyfGr94QQvQShK5BTOab58pU7RFSRWT/D47JyvXGQMFsPOKRvtQowOjtaZVZRJvDVzK3/iph13Gkq URTY1XHub/Qcp7iKYEqNh/LQK9N10i47OEjrGIaX9W4=
Archived-At: <>
Subject: Re: [EAT] Implicit vs Explicit Attestation (was Re: 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: Mon, 24 Sep 2018 22:47:04 -0000

Hi Henk,

Just commenting on your comments below. Will write later for suggested text about EAT for the BoF.

The intent is that EATs ARE always signed just like CWTs are always signed. The EAT draft just says "No particular signing algorithm or signing scheme is required” which means that the signing could be ECDAA, ECDSA, SHA-256 HMAC or anything you can fit into COSE.  There’s two reasons for this:

1) Claims must be defined independent of the signing scheme, so they work with lots of different signing schemes and become universal
2) To have flexibility in signing schemes in the short run, to let the market decide, to later standardize them when they are better understood

Maybe unsigned EATs are useful, but I’m not sure how or where. 

With EAT I typically see the HW manufacturer and such offering a web service to very EATs from their devices. The relying party gets a token from the devices and goes to the HW manufacturer for verification. Intel, Qualcomm, Google and maybe others have this now in some form or other.  This makes it less important to standardize the signing scheme.

However the claims are to be processed by thousands of relying parties making trust decisions on a payment by payment basis, so they need to be standardized. 

When the relying party interacts with the verification service, they will be told how much meaning the token carries. It will probably be at a relatively coarse level (e.g., HLOS, TEE, TPM or SE) like FIDO does. The typical relying party probably won’t want much more than that.

I’d say all claims are for evaluating trustworthiness and that trustworthiness is subjective. Different relying parties and different risk engines are going to process things differently. Some if it will be on an actuarial basis. 41st Parameter <> (now owned by Experian) is an example of a company that does risk engine. They probably base it on more than 41 parameters now (a claim and a parameter are similar).

Agree that some claims need to be evaluated against Reference Values.  However geographic location might be a better indicator of fraud for a particular type of transaction than failure to match a particular Reference Value. Personally, I don’t feel a need to taxonmize the difference.


> On Sep 24, 2018, at 4:06 AM, Henk Birkholz <> wrote:
> On 09/24/2018 02:05 AM, Laurence Lundblade wrote:
>> From the TCG paper < <>>  it looks to me that implicit refers to use of a deterministic process for creating an attestation key and device ID from a seed (the UDS) rather than explicitly putting an attestation private key and X.509 certificate (e.g., IEEE Device ID) in each device. That is a fine thing to do. No objection to that.
>> By inference, then I’d guess that IEEE Device ID is an example of explicit attestation.
>> From an attestation taxonomic view, I don’t think we can divide into implicit vs explicit.  There are many more variants such as EPID, other variants of ECDAA, other ways to set pub key crypto and IDs, attestation based on symmetric keys and so on. I haven’t read enough TCG documents to know for sure, but I doubt that the TCG taxonomy is sufficient to cover all of them.
> Implicit vs. explicit attestation is the most prominent facet of attestation procedures we intended to differentiate at the beginning. There are more facets and details to the concept, of course. Maybe it is of use, if we try to abstract the intent and meaning a bit more in this context:
> 1.) _Key Availability_: The availability of keys can have different meanings.
> If a private key can only be used, if a system has a specific status (please see the comments of Andreas in this thread), there is "more meaning" to the signature. A Verifier has to have an understanding of this meaning - and network protocols can provide this context via the remote attestation or from a TTP - there are different procedures how to provide that context information.
> There are more facets to this concept. For example, a Claimant create signatures using an available private key for the system it resides on or on behalf of another system, if I understand the ongoing discourse correctly.
> 2.) _Claim Intent_: Claims (signed or not, the EAT draft does not mandate signing, which is useful, I think) also can have different intents.
> Currently, I think, we are talking about:
> 2a.) _trusted claims_, in general, that are signed or accompanied by signature claims, that are not necessarily intended to be verified (not used as Attestation Claims), and that are of interest to post-processes (e.g. age or location claims).
> 2b.) _claims enabling the assessment of trustworthiness_ that are intended to create trust in the trustworthiness of a system (used as Attestation Claims) by appraisal of the Attestation Evidence they compose (e.g. comparison of a quote generate by an eSE/HSM or a list of executed software components with Reference Values).
> Laurence, do you find the complete scope of EAT fitting into this very high level description? Or is something vital missing, maybe even wrong, conceptually?
> Viele Grüße,
> Henk