IETF Logo Mail Archive

[Rats] About (E)UID's

"Salz, Rich" <rsalz@akamai.com> Thu, 06 February 2020 16:34 UTC

Return-Path: <rsalz@akamai.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 BAF8612006B for <rats@ietfa.amsl.com>; Thu, 6 Feb 2020 08:34:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
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 6TPvtJgxqMJI for <rats@ietfa.amsl.com>; Thu, 6 Feb 2020 08:34:45 -0800 (PST)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 A88F31200F4 for <rats@ietf.org>; Thu, 6 Feb 2020 08:34:44 -0800 (PST)
Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 016GRIja017555 for <rats@ietf.org>; Thu, 6 Feb 2020 16:34:43 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=12DxZFWuEFYLfCsIZu4ViAsPMUY7h9U/rp9ntLl2JNo=; b=nzPFiWURY2gUsyx2w7RjzsVpptjK8ftWid5zb/gwDzkC+cb4FIlakSMoCMkmCcT1RzdF kKVxH/m49wVbQmg0PodnnxsOGRfekkBCSZhOYjQbaC1tfkTpodyIa7WcFWUa7BaPWpkO 9jrRZaR2wCY5p6cykD8TicNwq4RnHI3YTwl3X6+F7kEojsUvJF3JQKxj4l/k0X9F//Gj zXf8/ncmptwJqPTqVdRbjHYusCfkUZO+A1wxq53gyomRo9XaW+3GvbDlrnJg4Sqs2o4O SERdhVUs1PBP63McladIPABKyAREMmQ8plF33ANjxzrbezCIIWk5WK4p+HsbIdSTh5OA 0A==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2y0n420bkw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <rats@ietf.org>; Thu, 06 Feb 2020 16:34:43 +0000
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 016GWCnA005587 for <rats@ietf.org>; Thu, 6 Feb 2020 11:34:43 -0500
Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2xykfu6sfu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for <rats@ietf.org>; Thu, 06 Feb 2020 11:34:42 -0500
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 6 Feb 2020 11:34:42 -0500
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Thu, 6 Feb 2020 11:34:42 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: About (E)UID's
Thread-Index: AQHV3QtUaUOLh4A2CU2Ls4Ypa3w67w==
Date: Thu, 06 Feb 2020 16:34:41 +0000
Message-ID: <8BDAAE2E-9803-4048-AD5B-59233708E6FB@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.22.0.200203
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.116.207]
Content-Type: multipart/alternative; boundary="_000_8BDAAE2E98034048AD5B59233708E6FBakamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-06_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=525 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2002060126
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-06_01:2020-02-06, 2020-02-06 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 priorityscore=1501 impostorscore=0 clxscore=1031 malwarescore=0 phishscore=0 lowpriorityscore=0 bulkscore=0 adultscore=0 mlxlogscore=505 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002060125
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/wZtInhYJHY7JJ6iltdBJcAV2xUw>
Subject: [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: Thu, 06 Feb 2020 16:34:48 -0000

I made a proposal during yesterday’s interim about EUID’s and I want to explain it here in more detail to the whole WG. I have made some clarifications.

We need ID’s.  Laurence has done a lot of good analysis on how many bits an ID needs to be to accommodate various users, devices, etc.  The TL;DR is that 128bits seems good for the size for now and at least the short-term future.

I suggest that the UID stays at 128bits. But in order to compare UID’s, relying parties should consider an “expanded” UID, which includes the SHA2 signature of the public signing key. For most cases, the “small” UID of 128 bits is sufficient to put into data structures, transport on the wire, and so on. Applications which present “unsigned” UID’s should either include a “key context” element, containing the hash. If not present, receiving applications should consider treat the key-id part as the SHA2 hash of the single zero byte.

One feature of this, as pointed out on the call, is that when a device gets a new owner, the expanded UID changes.

Hope this is useful.

v2.23.0 | Report a Bug | By Email