Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF charter updates?

Henk Birkholz <> Mon, 15 October 2018 14:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4CC62130E84; Mon, 15 Oct 2018 07:53:52 -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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aritzqrGoECe; Mon, 15 Oct 2018 07:53:48 -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 97259130E48; Mon, 15 Oct 2018 07:53:46 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w9FErhIf023549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 15 Oct 2018 16:53:44 +0200
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 15 Oct 2018 16:53:38 +0200
To: "" <>, "Jeremy O'Donoghue" <>, Denis <>
CC: "" <>
References: <> <> <> <> <>
From: Henk Birkholz <>
Message-ID: <>
Date: Mon, 15 Oct 2018 16:53:37 +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] [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: Mon, 15 Oct 2018 14:53:53 -0000

Hi Jeremy & Denis,

all these points of view have merit, I think.

Please have a look at these quotes:

> knowing the provenance of the device

> having the entity creator/manufacturer provide a set of claims which can be verified

> to know the characteristics of a device by issuing to the device a public key certificate which will only be issued to the device if it fulfills an expected set of functionalities.

To me, these descriptions seem to have different intents, scope or 
audience and require most certainly different work-flows, but 
semantically and in consequence representation-wise they also seem quite 

If you think of an identity document as a set of claims (potentially 
including a public key), that is signed and that can match one or more 
things, maybe all three types highlighted above are actually covered by 
the same identity document concept?

With respect to identity documents, I think it is safe so say that we 
can find common ground here rather easily. That said, the way how these 
identity documents come into existence, when and how they are deployed 
on the thing or associated with multiple things is another question. We 
most certainly do not want to end up with a "signing fool" that does not 
add value to the level of confidence (I am quoting Ned Smith here).

This has to be fleshed out explicitly for each scenario and the parts 
that are reused in every scenario should get special attention in the 
upcoming RATS architecture draft.

Identifying claims aggregated in an identity document most certainly can 
include device characteristics, public key(s), or claims about the 
intended functions and capabilities of the thing. Claims can even 
originate from Claimants that are not the thing itself, but external 
entities providing an assertion (e.g. these things are CC-certified).

All different composites of identifying claims have a specific shared 
intend in this context though, I think: expressing Attestation 
Provenance (again - one for one or more things of the same kind). And 
all of them originate from Claimants and therefore use a root of trust 
of measurement, I think.

That said, establishing trustworthy knowledge about attestation 
provenance is only the first step and provides the foundation for more 
complex attestation procedures. In any case, this seem to be required by 
every scenario that was highlighted so far and therefore will most 
certainly be covered in a deliverable.



On 10/15/2018 12:22 PM, Jeremy O'Donoghue wrote:
> On 12 Oct 2018, at 14:33, Denis < 
> <>> wrote:
>> The "Problem Statement" continues as follows:
>> (2) Today, there is no common, standard way for Relying Parties to 
>> know the provenance and characteristics of a device (e.g., an end-user 
>> device,
>> platform or endpoint, servers, IoT devices, device subsystems and 
>> sub-modules) that may be requesting services.
>> Knowing the provenance of the device is not always necessary. What is 
>> important is to know that a specific set of functions is (securely) 
>> supported by the device.
>> There already exists a common way to know the characteristics of a 
>> device by issuing to the device a public key certificate which will 
>> only be issued to the device
>> if it fulfills an expected set of functionalities. In such a case a 
>> syntax for a trusted claim sets**is not needed.
> This is indeed a possible way to address the problem, but suffers from 
> challenges which come down to:
> - Who issues such certificates. An option is that there is some form of 
> security certification behind this issuance otherwise it is of very 
> limited value.
> - In order to capture the wide variety of different devices (I prefer 
> "entity" here as it is more general than "device"), many different forms 
> of such certificates would be required. This ends up being much the same 
> thing as a set of claims.
> Given the multiplicity of entities for which attestation might be 
> useful, it seems to me that having the entity creator/manufacturer 
> provide a set of claims which can be verified is more flexible than 
> requiring a certificate. It seems likely to me that where a formal 
> security certification is needed there will be a certificate issued by 
> the Certifying Body as one of the claims about an entity, but I can 
> think of many cases (supply chain management, to take just one example) 
> where provenance is by far the most useful information.
> I'm not in favour of changes to the charter in this direction.
>> The simplest cases should also be part of the framework.
>> Note: I personally appreciate that privacy is an aspect that 
>> will/should be taken into consideration.
>> Denis
>>> As with the earlier draft, there are many references to verify and
>>> verifier in the lead up to the deliverable but no deliverables describing
>>> verification rules. I'd like to see rules in one of these documents and
>>> think it worth citing in the deliverables. Are bindings to certificate
>>> management protocols out of scope?
>>> On 10/11/18, 9:49 AM, "RATS on behalf of Henk Birkholz"
>>> < on behalf of>  wrote:
>>>> Hi all,
>>>> sorry for the delay. Please find an updated charter proposal here:
>>>> The BoF proponents tried to merge all comments and proposals on
>>>> keystores, existing solutions, provenance & device characteristics, etc
>>>> that were raised on the list - and align them in homogeneous fashion.
>>>> This draft is intended to focus the discussion and improve the wording.
>>>> Viele Grüße,
>>>> Henk
>>>> On 10/06/2018 08:23 AM, Laurence Lundblade wrote:
>>>>> Hi Henk,
>>>>> Bangkok IETF is getting close, will you be able to update the charter
>>>>> for the attestation BoF to properly include EAT?  I sent you some text
>>>>> that just needs to be pasted along with some comments. It doesn’t look
>>>>> like there’s been any updates.
>>>>> LL
>>>> _______________________________________________
>>>> RATS mailing list
>>> _______________________________________________
>>> EAT mailing list
>> _______________________________________________
>> EAT mailing list
>> <>
> _______________________________________________
> EAT mailing list