Re: [Rats] About (E)UID's

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 14 February 2020 07:26 UTC

Return-Path: <mcr@sandelman.ca>
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 B74BA12009C for <rats@ietfa.amsl.com>; Thu, 13 Feb 2020 23:26:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 tmSFwfstr4Ed for <rats@ietfa.amsl.com>; Thu, 13 Feb 2020 23:26:53 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8548D12008C for <rats@ietf.org>; Thu, 13 Feb 2020 23:26:53 -0800 (PST)
Received: from dooku.sandelman.ca (unknown [185.201.63.254]) by relay.sandelman.ca (Postfix) with ESMTPS id C376F1F459 for <rats@ietf.org>; Fri, 14 Feb 2020 07:26:51 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id A0A6E1A088C; Fri, 14 Feb 2020 07:26:48 +0000 (GMT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "rats@ietf.org" <rats@ietf.org>
In-reply-to: <4680A258-DBCD-4464-91ED-DE239C55701B@island-resort.com>
References: <8BDAAE2E-9803-4048-AD5B-59233708E6FB@akamai.com> <1C16DAA0-D03B-417C-894A-30C4015AEED7@island-resort.com> <DBBPR08MB49031E717F69E4CF58CF67A1EF1C0@DBBPR08MB4903.eurprd08.prod.outlook.com> <509C8229-20DC-4888-BE1D-9109733A9E2D@intel.com> <5B9516E6-1441-462E-86D2-B630B32CE1C7@island-resort.com> <DBBPR08MB4903356ED09601AA7A6006FAEF180@DBBPR08MB4903.eurprd08.prod.outlook.com> <07A3E092-068F-4E35-8C39-D290FDB8CFDC@island-resort.com> <DBBPR08MB4903840E6D30A59083F8B119EF1B0@DBBPR08MB4903.eurprd08.prod.outlook.com> <6CD93307-E6F2-40F9-B041-FEBF5AD226CA@akamai.com> <DE7B37F5-5675-4F3D-B279-5FB92107BED4@arm.com> <4680A258-DBCD-4464-91ED-DE239C55701B@island-resort.com>
Comments: In-reply-to Laurence Lundblade <lgl@island-resort.com> message dated "Wed, 12 Feb 2020 17:16:43 +0000."
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.2.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Fri, 14 Feb 2020 07:26:48 +0000
Message-ID: <28219.1581665208@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/LjemYnUD7H0X-6paZaYEv14Bvgw>
Subject: Re: [Rats] About (E)UID's
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, 14 Feb 2020 07:26:56 -0000

Laurence Lundblade <lgl@island-resort.com> wrote:
    > Here’s some text we might add:

    > UEID’s are intended to be globally unique permanent device identifiers,
    > but these characteristics rely on the implementors of device following
    > the specification well. A relying party, particularly one dealing with
    > a very broad variety of devices from different manufacturers, may wish
    > to take into account other data in the token to uniquely identify the
    > device. For example they might consider a hash some or all of the UEID
    > + oemid + hw_version + signing_key as the unique identifier of the
    > device. Note these are all values that are permanently set for a device
    > at time of manufacturer.

Since the Relying Party needs to vest trust in the Verifier, it seems that
the verifier out to calculate this hash, and it should be a new claim.

a) it has access to this information.
b) there are fewer Verifiers than Manufacturers
c) the OEMID/HW_Version may well be personally identifier information which
   should not be passed on to the Relying Party.
   (Although I guess, if we are forming a hash over it, it becomes trackable)

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [