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

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 14 February 2020 11:50 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 3D806120825 for <rats@ietfa.amsl.com>; Fri, 14 Feb 2020 03:50:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.501
X-Spam-Level: **
X-Spam-Status: No, score=2.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 dH0CXjDrj595 for <rats@ietfa.amsl.com>; Fri, 14 Feb 2020 03:50:14 -0800 (PST)
Received: from relay.sandelman.ca (minerva.sandelman.ca [IPv6:2a01:7e00::3d:b000]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50E921200F6 for <rats@ietf.org>; Fri, 14 Feb 2020 03:50:13 -0800 (PST)
Received: from dooku.sandelman.ca (unknown [46.183.103.8]) by relay.sandelman.ca (Postfix) with ESMTPS id 096911F459 for <rats@ietf.org>; Fri, 14 Feb 2020 11:50:11 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 748121A2B90; Fri, 14 Feb 2020 12:49:55 +0100 (CET)
From: Michael Richardson <mcr+ietf@sandelman.ca>
to: "rats\@ietf.org" <rats@ietf.org>
In-reply-to: <28219.1581665208@dooku>
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> <28219.1581665208@dooku>
Comments: In-reply-to Michael Richardson <mcr+ietf@sandelman.ca> message dated "Fri, 14 Feb 2020 07:26:48 +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 12:49:55 +0100
Message-ID: <10690.1581680995@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/URtyCDeNn07f5kEDyYsrZIetPUo>
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 11:50:16 -0000

Michael Richardson <mcr+ietf@sandelman.ca> wrote:
    > 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

Let me restate: a Relying Party has relationships with fewer Verifiers than
there are Manufacturers.  Maybe worst case Manufacturers:Verifiers will be
1:1, but in better cases where a Verifier providers services for many
manufacturers that ratio could be different, and thus in general, the RP will
have fewer relationships with 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    [ 
	
    > _______________________________________________
    > RATS mailing list
    > RATS@ietf.org
    > https://www.ietf.org/mailman/listinfo/rats

-- 
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-