Re: [Rats] UEID where an instance is a group member

Laurence Lundblade <lgl@island-resort.com> Fri, 27 March 2020 17:33 UTC

Return-Path: <lgl@island-resort.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AAE3A0FD8 for <rats@ietfa.amsl.com>; Fri, 27 Mar 2020 10:33:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8H8UrmVSWe6 for <rats@ietfa.amsl.com>; Fri, 27 Mar 2020 10:33:51 -0700 (PDT)
Received: from p3plsmtpa11-03.prod.phx3.secureserver.net (p3plsmtpa11-03.prod.phx3.secureserver.net [68.178.252.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D669E3A0F9D for <rats@ietf.org>; Fri, 27 Mar 2020 10:33:13 -0700 (PDT)
Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id Hsr2jT8cQXZxOHsr3j9GH7; Fri, 27 Mar 2020 10:33:13 -0700
X-CMAE-Analysis: v=2.3 cv=R5B95uZX c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=7CQSdrXTAAAA:8 a=_hK6EUOQByftzJWKJZEA:9 a=QEXdDO2ut3YA:10 a=YG3Ht6hDksvwzeR5:21 a=_W_S_7VecoQA:10 a=a-qgeE7W1pNrGK8U0ZQC:22
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <EBDAF6CF-B1D5-4AF8-9E69-176263EC58D6@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BBDD5784-D5BF-4670-9CB0-1F7795FCF0D5"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 27 Mar 2020 10:33:12 -0700
In-Reply-To: <DB594CB9-493E-4DDC-A41A-909B527A4976@arm.com>
Cc: "Smith, Ned" <ned.smith@intel.com>, "rats@ietf.org" <rats@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
To: Thomas Fossati <Thomas.Fossati@arm.com>
References: <C205FBA7-71A7-4987-AE82-DA855BF86B84@intel.com> <C3A707FF-4AF1-4E0A-BABB-8EE2F52A2D2B@island-resort.com> <33f462bb-979e-80cc-9c27-af1e3b77d5e6@sit.fraunhofer.de> <7C94FAC2-AADB-4397-A50D-4FBB11EFCABA@intel.com> <A4C4246B-400F-4C38-839C-6747620C35C2@island-resort.com> <4F616CB6-6F42-43CE-94A6-ADD155900535@intel.com> <DB594CB9-493E-4DDC-A41A-909B527A4976@arm.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfGwIiRZWjSb2H8RVah9CtSEbZhH9c0AIqbnM/0v3MHZdi0rGFu2a7wQFn8C6pOYJNkUjykwcADEyyDxLX0mSvpQMg3gXGeSp82kawtrXoUhi7+JqKOHX zte5G/LNlR8wNoWlIIO2rL6/IiNeQ3hegNlYryh9p3p+I6/iDYmXvIP+19AcpQjVFXtRBUw+mfuuozmGoBWOLT9fJ3CUuHKKpIUPpPJQ7OmYV3ZYlk+AnTHx FpzUoc+O8AnA1kMMeoWqbK0VYflp19CyDEX02gYw5fw=
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/qZbSJZJgQIvJOcIoZjWxyhUqln8>
Subject: Re: [Rats] UEID where an instance is a group member
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2020 17:34:01 -0000

> On Mar 27, 2020, at 4:03 AM, Thomas Fossati <Thomas.Fossati@arm.com> wrote:
> 
> In particular, there might be attributes of an attesting endpoint which
> are not necessarily related to the signing key.  For example, the
> linking to certification data, and more generally anything that has a
> chance to change during the lifetime of the device (or is not known at
> manufacturing time) is more easily supplied via endorsements to the
> verifier.  In my view, EUID/EGID is the handle to all this data, which
> MAY include the key used to verify the signature.

Ahhh. There’s the source of the issue: what bits in attestation evidence give the binding to the endorsement?

Since I didn’t understand endorsements very well until Berlin, there’s nothing that I’ve (consciously) put into EAT to handle that.

Seems like a critical point to be addressed in EAT and in architecture. :-)

LL