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

Henk Birkholz <> Mon, 24 September 2018 11:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DC84E130E89; Mon, 24 Sep 2018 04:07:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NBhSE_X0wvIe; Mon, 24 Sep 2018 04:07:18 -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 079A9130E53; Mon, 24 Sep 2018 04:07:16 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w8OB7CJC023198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Sep 2018 13:07:13 +0200
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 24 Sep 2018 13:07:05 +0200
To: Laurence Lundblade <>
CC: Denis <>, <>, <>
References: <> <> <> <> <> <> <>
From: Henk Birkholz <>
Message-ID: <>
Date: Mon, 24 Sep 2018 13:06:55 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: []
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 11:07:22 -0000

Hello Laurence,

please find as my reply a general question up front and specific 
comments in-line.

The gap addressed by your proposed text is about keys and claims, I 
think. In essence:

* provision / store / derive / establish the key material, and
* standardization of claims

Is that correct?

I think that is not resembling the complete picture about EAT. Is that 
also correct?
If so, could you provide us with an abstract problem statement and a 
corresponding description of the gap the EAT scope intends to address? 
What is missing in my very short summery above? (maybe there is an email 
I did not find ad-hoc that does address these gaps already)

A single comment in-line.

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 

1.) _Key Availability_: The availability of keys can have different 

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 

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, 

Viele Grüße,


> EAT’s approach to this is to just say that tokens are signed using the 
> COSE format (and probably JOSE too) and to focus on the definition of 
> claims with the idea that the claims can be used with lots of different 
> ways of signing and attestation key set up. This seems like clear 
> achievable work.
> I think it is OK to work on standardization of the attestation key and 
> signing set up. We will probably need several such efforts as one size 
> definitely won’t fit all.
> So I propose we replace the internal / external intro sentence and 
> bullets with this:
>     There are many ways to provision / store / derive / establish the
>     key material used by the Attester to digitally sign claims that are
>     transmitted to the Verifier. These might include EPID, some variant
>     of ECDAA, IEEE DeviceID, TC Implicit Identity Based Device
>     Attestation, other public key based schemes and schemes using
>     symmetric keys. They might also include a privacy proxy or privacy CA.
>     The standardization of claims is to be largely independent of these
>     different ways. Any such way of setting up this key material must be
>     able to secure claims expressed in CBOR or JSON directly or
>     indirectly (e.g., a hash of the claims).

I think it is a good idea to include both CWT and JWT.

>     The WG may choose to standardize some of the ways to provision /
>     store / derive / establish the key material. 
> I know the last sentence is a bit wishy washy for a charter. Personally, 
> I was interested in punting that work until EAT is done and there is 
> more operational experience and practice. If there’s a few specific 
> scheme we want to go after, maybe we do that. One or two might be 
> TCG/TPM oriented. Another that works for Android Key Store and FIDO 
> attestation.
> LL
>> On Sep 21, 2018, at 8:44 AM, Henk Birkholz 
>> < 
>> <>> wrote:
>> Hello Laurence,
>> please find replies and comments in-line (and sorry for replying in 
>> the wrong order...).
>> On 09/20/2018 11:29 PM, Laurence Lundblade wrote:
>>> Forking the discussion here to focus on implicit/explicit 
>>> attestation. That seems to be a new term invented in this WG Charter 
>>> as I haven’t seen it elsewhere. I’m not sure what it means yet. It 
>>> seems to have something to do with how the loop is closed in the 
>>> Attestation Model below. In particular the role of the Entity 
>>> Manufacturer.
>> The term "explicit attestation" wrt to remote attestation is actually 
>> "new" in a sense that "implicit attestation" got a sharper focus and 
>> is now used in open documents. In consequence, specializing "explicit" 
>> attestation next to implicit attestation (wrt to remote attestation) 
>> was the smallest and most intuitive semantic step - terminology-wise.
>> Google'ing for (implicit) attestation protocols, I found these TCG 
>> documents.
>> The first one uses "implicit attestation" for "strong Device Identity" 
>> (same approach as the EAT). The second one is 7 years older and (to my 
>> surprise, actually), defines both Attestation and - in fact- 
>> Attestation Evidence. I have to admit that we have not taken these 
>> definition into account, but will in the next iteration. There does 
>> not seem to be a conflict. Also, the semantic equivalent to RIMM seems 
>> to be Template Reference Manifest in the second document.
>> > 
>>> The obvious way to do this (kind of like TLS certs, but flipped):
>>> - The Entity Manufacturer puts a private key + X.509 certificate in 
>>> each Entity (device) it makes
>>> - This Entity (device) X.509 certificate is signed by the Entity 
>>> Manufactures Root Key
>>> - The Entity uses its private key to sign some Claims
>>> - The Entity sends the signed claims and its X.509 cert to the 
>>> Relying Party
>>> - The Relying Party gets the Entity Manufacturers Root Cert in a one 
>>> time operation and saves it
>>> - The Relying Party chains the device X.509 per to the Entity Root Cert
>>> - The Relying Party uses the public key in the device X.509 to verify 
>>> the signature on the Claims
>> This is, in essence, _the_ reference work-flow of implicit 
>> attestation, I think. Please note that here the signatures are 
>> verified (which is the implicitness) in contrast to appraising the 
>> signed (temper-evident, amongst other characteristics) claim sets via 
>> reference values (which an Verifier is capable to do wrt explicit 
>> attestation).
>>> One of my guesses for what implicit attestation is — The RP (Relying 
>>> Party) does not get any root keys or such from the Entity 
>>> Manufacturer or a CA or a trusted third party. They verify the 
>>> signature solely based on what is in the signed token they received. 
>>> The RP probably did send a nonce and the Entity signed it, so there 
>>> is proof-of-posession of the Entity's key, but that key and device 
>>> could be any device so little is proved. The RP can remember the 
>>> Entity’s key and expect it to be the same next time to give it some 
>>> value. This is called self-attestation of surrogate attestation in 
>>> FIDO. It not considered very secure. The loop is not closed.
>> I assume that the key remembered by the Relying Party is a public key 
>> - inside the x.509? Very likely it is not the private key you did the 
>> proof-of-possession for. In any case, please see above wrt implicit 
>> attestation.
>> I am not sure what to make of "verify the signature solely based
>> on what is in the signed token they received" - I assume that is 
>> different from verifying the signature, as the RP did not get anything 
>> from the corresponding CA?
>> I am also assuming that the "RP can expect the same key again" via the 
>> accompanying x.509 and therefore can infer characteristics on how the 
>> claims should be composed (again)?
>> As the current (wordy) charter text illustrates proof-of-possession is 
>> the basis for implicit attestation and in that regard I think we are 
>> actually in alignment here.
>>> Another one of my guesses — The RP does get key material with which 
>>> to perform verification, but it is not directly from the Entity 
>>> Manufacturer. Instead there is some CA or trusted 3rd party in the 
>>> loop. This is a realistic scenario. The loop is closed so it is secure.
>> This is a work-flow that I would very much like to flesh out, 
>> homogenize and include more... explicitly :)
>>> I see this as a topic for technical discussion, not something for 
>>> definite in the charter.
>> Well, apparently we are under the impression of... yes and no. In 
>> order to get goals/deliverables and scope right we have to agree on 
>> what term has which technical meanings, implications and dependencies. 
>> Assuming that background and terminology could be pruned from the 
>> charter at some point of consensus and then be... and that is my 
>> problem here... maintained without changing their meaning (and 
>> therefore not implicitly changing the charter).
>> Carsten highlighted the problems with that approach, so while these 
>> definitions may go down to a technical level, they are essential to 
>> the meaning of the charter. It is a bit of a hen & egg problem, I am 
>> afraid, due to the terminology document (evolving into an architecture 
>> document) being in flux.
>> Viele Grüße,
>> Henk
>>> LL
>>>> On Sep 18, 2018, at 8:56 AM, Denis < 
>>>> <> <>> wrote:
>>>> Hi Henk,
>>>> I fear that we don't understand each other.
>>>>> Hi Denis,
>>>>> there are a lot of topics addressed by your reply. First of all, 
>>>>> thank you for the the feedback!
>>>>> We attempted to create a document that is as inclusive as possible 
>>>>> - within reason. Hence, it is also solution agnostic.
>>>>> As Andreas just said, Proof-of-Possession of a secret key is 
>>>>> intended to be captured by Implicit Attestation. In other words:
>>>>> if you are able to use that secret key to sign something, it 
>>>>> implies (that is the "implicitness" here) that "that device has 
>>>>> some well known properties".
>>>> No. If you are able to use a secret key to sign something, it does 
>>>> not mean that you are using a device.
>>>> If a device is able to sign something, it does not necessarily mean 
>>>> that what is signed really comes from the device, unless "that 
>>>> device has some well known properties".
>>>>> The definition of implicit attestation might require some 
>>>>> improvement, I assume (and I don't mean by adding even more words).
>>>>> I am a bit confused by the use of "attestation certificate", 
>>>>> "private key" and "origin of data exchange" in your reply.
>>>>> If "certificate" in your proposal:
>>>>>> "shared attestation certificates" to designate attestation 
>>>>>> certificates that are specific to a batch of devices from the same 
>>>>>> model (like in FIDO),
>>>>>> "individual attestation certificates" to designate attestation 
>>>>>> certificates that are specific to each device.
>>>>> means identity document, the concepts of "Singular Identity", 
>>>>> "Shared Identity", and "Group Identity" are already subsumed in the 
>>>>> IETF by the definition of "Identity" in RFC4949.
>>>>> Maybe that fact is a little bit too hidden at the end of the 
>>>>> Background section that refers to "cryptographic identities". 
>>>>> Highlighting that more up front and referencing RFC4949
>>>>> explicitly could address that issue.
>>>> It does not mean anything from the above list. My arguments have 
>>>> nothing to do with "Identity". Typically, an Attestation Certificate 
>>>> it is an X509 certificate, as in FIDO.
>>>>> Correspondingly, the same secret key can be enrolled on multiple 
>>>>> devices, but that is not the same thing as enrolling the same 
>>>>> (group/shared) identity document on multiple devices.
>>>> The private key of a device is never enrolled but is placed in the 
>>>> device by the manufacturer of the device (or the entity that 
>>>> personalizes it before making it available to an end-user);
>>>>> The smallest identity document I can think of would be a signed 
>>>>> public key. More commonly today, it would be an ASN.1-based 
>>>>> identity document, I assume.
>>>> My arguments are fully unrelated to "identity documents".
>>>>> Jumping a bit to the end:
>>>>> Local Attestation is described in the Background section and is 
>>>>> referred to again in the Scope section as out-of-scope.
>>>> This is fine.
>>>>> That said, as Local Attestation can be a prerequisite for Remote 
>>>>> Attestation and it also might require some provisioning (via 
>>>>> network protocols) in order to work,
>>>>> provisioning protocols that enable local attestation are currently 
>>>>> considered in-scope.
>>>>> The fact that the definition of Attestation Evidence is difficult 
>>>>> to understand could be the biggest issue here, I think. Especially, 
>>>>> because it is the basis for
>>>>> the definition of Remote Attestation, as you highlighted. I will 
>>>>> come back to this topic as soon as I have a few more free cycles :)
>>>>> Viele Grüße,
>>>>> Henk
>>>> ...
>> _______________________________________________
>> EAT mailing list
>> <>