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

Jeremy O'Donoghue <> Mon, 15 October 2018 10:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A9726126BED for <>; Mon, 15 Oct 2018 03:22:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Status: No, score=-4.299 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, URIBL_BLOCKED=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 RdB1ah2Km0ZQ for <>; Mon, 15 Oct 2018 03:22:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D59D6130E1E for <>; Mon, 15 Oct 2018 03:22:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1539598929; x=1571134929; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FPhZT01nJPwYuZAt186022rgn/oikjsPLf+0xKJwhfw=; b=jEC20agdH8TxHfUn0gIcrQYh7AB3U13vmIK1v/NB4ve3Rk1mdXuqcw9F gS+7jgFqvd2148uKQk2HiVrwuF3+8HNlqDWVnlScXyg8Vy/HBNo5VeIx1 7uCTizjmhk+7aTUT85JbKGTOYV7qMxwvFGluUkBpwGk4n4iL6n4yMGv7/ 8=;
X-IronPort-AV: E=Sophos;i="5.54,384,1534802400"; d="scan'208,217";a="1341350"
Received: from ([]) by with ESMTP; 15 Oct 2018 12:22:06 +0200
X-IronPort-AV: E=McAfee;i="5900,7806,9046"; a="6012749"
Received: from ([]) by with ESMTP/TLS/AES256-SHA; 15 Oct 2018 12:22:06 +0200
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 15 Oct 2018 12:22:04 +0200
Received: from ([]) by ([]) with mapi id 15.00.1365.000; Mon, 15 Oct 2018 12:22:04 +0200
From: Jeremy O'Donoghue <>
To: Denis <>
CC: "" <>
Thread-Topic: [EXTERNAL] Re: [EAT] [Rats] Attestation BoF charter updates?
Thread-Index: AQHUYaTykKrRlZ03gEOf2t41ZpAaRqUbe3kAgASBiwA=
Date: Mon, 15 Oct 2018 10:22:04 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
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_73EF502EB68C410683114897B4F2DF8Cqtiqualcommcom_"
MIME-Version: 1.0
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 10:22:14 -0000

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.

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,


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.


RATS mailing list<>

EAT mailing list<>

EAT mailing list<>