Re: [Cwt-reg-review] [EXTERNAL] Re: Registration of Entity Attestation Token claims in the CWT registry

Roman Danyliw <rdd@cert.org> Thu, 13 January 2022 16:37 UTC

Return-Path: <rdd@cert.org>
X-Original-To: cwt-reg-review@ietfa.amsl.com
Delivered-To: cwt-reg-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1498E3A165C; Thu, 13 Jan 2022 08:37: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=seicmu.onmicrosoft.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 sqomSTvsfq_9; Thu, 13 Jan 2022 08:37:48 -0800 (PST)
Received: from USG02-CY1-obe.outbound.protection.office365.us (mail-cy1usg02on070b.outbound.protection.office365.us [IPv6:2001:489a:2202:d::70b]) (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 7D1DD3A1207; Thu, 13 Jan 2022 08:37:47 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=gc8d5PImTxerhd7mjHIGx54RaKLc0qKBq6h7UZNhoMRSICVClF+jG1BEFVNedVbHjEPiqDmH1UylbjDo9Yhds+88hZ+ZN6GHYBjkz+/gkNQ2iHxPEkjAZ0abKqdMbadsV/28SDQ/Ryde4zGgWA67cFo1Pm9BprFNxZV8868srJx/5D5/GtYclYwGto+R8tksT+1C2MQ5gXy2HZ0Z1XZgg5sYrAP0iK7EoLzLvsrW9zU+r1T9b/bde7lLn+HAZ/znTER+PUbWQyfe9CYNfXpuio4iXZ80fhYuC0ymiM3xCPbav/HJOlAx0P7WhBs1c7GRd7bDjfy7TJ9D7Fd+X+ZHAQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=eM+FB8NT3BKuCc0ay+iIrIG+hLltB4KINOvvvRwY1ac=; b=WI2l3RBsCHW6lWHWd+fVQSEEpiUT+HE289sSwp9G6V7eOS8EWead7PoSVcNf4D9Pd93r2qF7+TGorHh7wVpnlOgbbjYLwS1xC4IiSOmSbGM5rF52HnSarDwulxoPV9pSE8NRQXcWW+Tu5bakgjCNGRx+qrRo1LHkTTVeCYpCAKCP2Wj9Tky0nHMZIyYHMrVW9veADUqQD9o8fxST0h5UTp2R3v9xCGGqOvUc2qgLOQg+WWOroaBmY7HxTaErrPncOOuCpghO82jv30zuIbbMTQzyKC2hQAyVb1Ma6Z2+EgWP+KxOpuGL9qqPObkJHF4DOvqnzwhKlaIM65fw4MDegg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cert.org; dmarc=pass action=none header.from=cert.org; dkim=pass header.d=cert.org; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seicmu.onmicrosoft.com; s=selector1-seicmu-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eM+FB8NT3BKuCc0ay+iIrIG+hLltB4KINOvvvRwY1ac=; b=AmhetXIKrSmGYoqbtpwKc66N74LxoR+QF6VH5Afis64RwM9fuwffIWZGeVDLoDC2wUeynDbaI5jsY/mP7keYcReOgu8VPJ+71U+rdf8pyTFmnWtmvaZLGMKvUVCIWr2XF1Z6shwYbsClq95qIA0IWO0VU1qf6sopHEl5TPtz2xA=
Received: from BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:168::11) by BN2P110MB1461.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:17b::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4888.10; Thu, 13 Jan 2022 16:37:42 +0000
Received: from BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM ([fe80::f0be:6d5:6544:cce0]) by BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM ([fe80::f0be:6d5:6544:cce0%4]) with mapi id 15.20.4888.011; Thu, 13 Jan 2022 16:37:42 +0000
From: Roman Danyliw <rdd@cert.org>
To: Giridhar Mandyam <mandyam@qti.qualcomm.com>, Mike Jones <Michael.Jones@microsoft.com>, Laurence Lundblade <lgl@island-resort.com>
CC: Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>, "cwt-reg-review@ietf.org" <cwt-reg-review@ietf.org>, Ned Smith <ned.smith@intel.com>, "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, rats-chairs <rats-chairs@ietf.org>, Roman Danyliw <rdd@cert.org>
Thread-Topic: [EXTERNAL] Re: Registration of Entity Attestation Token claims in the CWT registry
Thread-Index: AdfC4h5/iyKlcunsQMW+S9Z9NAjwkKxgcVbA1CpYyQCAAEUiAP//r/GQ//9NJkA=
Date: Thu, 13 Jan 2022 16:37:42 +0000
Message-ID: <BN2P110MB1107A9F9995AECF1DB81E124DC539@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
References: <BYAPR02MB44220D6BED944249AC4E32B981BA9@BYAPR02MB4422.namprd02.prod.outlook.com> <SJ0PR00MB10050DA0F62755FCE7028000F5539@SJ0PR00MB1005.namprd00.prod.outlook.com> <2E0FD21A-4CB3-487A-980D-494EDE316674@island-resort.com> <E34599A0-B436-4D23-A67D-23995FFBA06B@island-resort.com> <SJ0PR02MB835353146FFADE9C98E2479C81539@SJ0PR02MB8353.namprd02.prod.outlook.com> <SJ0PR00MB100547B70B0DB6E150E9DA8DF5539@SJ0PR00MB1005.namprd00.prod.outlook.com> <D834724B-D80F-4516-8D62-CE53F7D0B763@island-resort.com> <SJ0PR00MB1005DEBD050002C47BEDF578F5539@SJ0PR00MB1005.namprd00.prod.outlook.com> <SJ0PR02MB8353344FC438C0E7F792999081539@SJ0PR02MB8353.namprd02.prod.outlook.com>
In-Reply-To: <SJ0PR02MB8353344FC438C0E7F792999081539@SJ0PR02MB8353.namprd02.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-01-13T10:31:09Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=654d2c84-9d02-4934-a63b-d55669957ed1; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cert.org;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8b21110d-54c1-4193-9362-08d9d6b30576
x-ms-traffictypediagnostic: BN2P110MB1461:EE_
x-microsoft-antispam-prvs: <BN2P110MB1461139D8C842C261DABADD2DC539@BN2P110MB1461.NAMP110.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:3513;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 1tlq7huPpOETDx97Jy0vaTYFcAMogNZ8bUvWOIt66EpI8ax3V3B+AHne74l09Er5V7J6PoOY7IRKqJmQu6SRtAB+JYBbrDIhDZAByL52pJXYzdtRs2pAqefiuNGFOBc6WE15+0K4zr4Bhq1Do2zFIby/S+yJ80Hlmn+MEElyw5pPOMCdfbPcNS+0BPI+nrmd/uai8lWXFmRxbAjJBdsvvFUB9FANTnFx4MPwrdi20+wrtXbOYpzpB3Cd09u1gc9TyCuF/YO3kiLLW57brC0sGm/qBySXg7EFNjkyGyfz+FOysnl5o9YsYTZ1jQlzCju7nha7UzeTzbItOCqz9B7FJZMZAcfnNiqIZMOWCRmAG/WJRy7GvxuarPnRk+MHBYpRQ/cqqhLr/mgI4gVACWknht4OS7jo3dgUvu4d8bkLBNMwrLRoO8rDWui+Z93fkxJ1g1ny3q/D/P2nHCBLSMpO2GPjkANW9oNKk04Ms8UunKsSi7nzpOStGiL1kP2RQYod4BWL3UXGiRcy4+kUoRlwiueW2pu/QQwkl+uMYl/tSRqh0fnH4CYAUL6A5stPQriXBvhyaC6E0K0kUy9HqIO7TrXAahZvtF1viR13QPdZqieiChvfgmV+YEApovlpU4Y+0ezvRPCcdfzXzKKFC0yeqvh0qNKHicMYrz2JqAvMILo=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(55016003)(166002)(21615005)(966005)(82960400001)(9686003)(52536014)(5660300002)(7696005)(122000001)(64756008)(66556008)(71200400001)(45080400002)(38100700002)(498600001)(8676002)(30864003)(66446008)(66946007)(2906002)(83380400001)(110136005)(54906003)(86362001)(8936002)(6506007)(99936003)(107886003)(33656002)(38070700005)(66476007)(53546011)(4326008)(76116006)(186003)(26005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: EfSlLDxdCchlGfoAmmPyC/AgfzXG8LiDyHOVX98iSRrBTd+qWJF/OlYdxjhGNGymEesjrkyib/ziw/QPR2emboMHdnGjiy7wzJbNt+LcE1MZiisnxlOZUQeWTAfi0A4fK1taQ3t9jtVJ8wsR3ZTBGQ==
Content-Type: multipart/mixed; boundary="_004_BN2P110MB1107A9F9995AECF1DB81E124DC539BN2P110MB1107NAMP_"
MIME-Version: 1.0
X-OriginatorOrg: cert.org
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 8b21110d-54c1-4193-9362-08d9d6b30576
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2022 16:37:42.7667 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 95a9dce2-04f2-4043-995d-1ec3861911c6
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN2P110MB1461
Archived-At: <https://mailarchive.ietf.org/arch/msg/cwt-reg-review/sHf0URza9Xt58jRRKZpaxqbeUDk>
X-Mailman-Approved-At: Thu, 13 Jan 2022 11:22:38 -0800
Subject: Re: [Cwt-reg-review] [EXTERNAL] Re: Registration of Entity Attestation Token claims in the CWT registry
X-BeenThere: cwt-reg-review@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: CWT Registry Review <cwt-reg-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cwt-reg-review>, <mailto:cwt-reg-review-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cwt-reg-review/>
List-Post: <mailto:cwt-reg-review@ietf.org>
List-Help: <mailto:cwt-reg-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cwt-reg-review>, <mailto:cwt-reg-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jan 2022 16:37:55 -0000

Hi all!

I wanted to acknowledge that I got this note, but I am not up-to-speed on the issue and need to catch-up before providing a meaningful response.  A search of my mailbox also found this related thread which I attached.

Roman

From: Giridhar Mandyam <mandyam@qti.qualcomm.com>
Sent: Thursday, January 13, 2022 10:35 AM
To: Mike Jones <Michael.Jones@microsoft.com>; Laurence Lundblade <lgl@island-resort.com>; Roman Danyliw <rdd@cert.org>
Cc: Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>; cwt-reg-review@ietf.org; Ned Smith <ned.smith@intel.com>; Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com>; Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>; rats-chairs <rats-chairs@ietf.org>
Subject: RE: [EXTERNAL] Re: Registration of Entity Attestation Token claims in the CWT registry

+ Roman D.

I would like to escalate this to the AD.  Note that the EAT editors acted in good faith in the expectation that the RATS  chairs would address early allocation, and we were assured last March that there was no issues with the requested values.  As a result, we put off Last Call for the draft and went forward with guidance to other SDO’s (e.g. FIDO Alliance, GlobalPlatform) that these claim values were stable.

Now for the first time we are finding out that (a) the values called out in the spec are not acceptable as per expert review criteria, and (b) the RATS chairs never initiated the process of pre-registration in the first place.

My request to the AD is simple:  allow for pre-registration of the values as called out in the current EAT draft.  If this is not possible (and it looks likely that it is not), then my additional request is that the AD directly manage shepherding of this spec to Last Call and RFC as I believe communication between the EAT editors and the RATS Chairs has broken down and the RATS Chairs are not driving consensus decisions from the Working Group with respect to this spec.

-Giri

From: Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>>
Sent: Thursday, January 13, 2022 2:39 AM
To: Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>>
Cc: Giridhar Mandyam <mandyam@qti.qualcomm.com<mailto:mandyam@qti.qualcomm.com>>; Jeremy O'Donoghue <jodonogh@qti.qualcomm.com<mailto:jodonogh@qti.qualcomm.com>>; cwt-reg-review@ietf.org<mailto:cwt-reg-review@ietf.org>; Ned Smith <ned.smith@intel.com<mailto:ned.smith@intel.com>>; Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com<mailto:ncamwing@cisco.com>>; Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com<mailto:kathleen.moriarty.ietf@gmail.com>>; rats-chairs <rats-chairs@ietf.org<mailto:rats-chairs@ietf.org>>
Subject: RE: [EXTERNAL] Re: Registration of Entity Attestation Token claims in the CWT registry


WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Early allocation did not occur.  If it had, the numbers would be assigned in https://www.iana.org/assignments/cwt/cwt.xhtml.  (For an example of early allocation listings, see claims 38, 39, and 40.)  Early registration, like normal registration, involves review by the designated experts, which also didn’t occur, because as far as I can tell, it wasn’t asked for.

I’m trying to help you get to stable assignments as soon as possible.  I know the value of having those.

Again, if you want stable assignments before upcoming interop events, I’d suggest making an early registration request by sending the registration request to cwt-reg-review@ietf.org<mailto:cwt-reg-review@ietf.org>.  It would be cleaner to do so by first changing the assignments in your IANA Considerations section to “TBD”, but you could also do so based on the current draft (realizing that the proposed assignments in the draft might not be the ones assigned by the designated experts and IANA).

You could have stable assignments within a few weeks if you choose to request them soon.

                                                       Best wishes,
                                                       -- Mike

From: Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>>
Sent: Wednesday, January 12, 2022 10:31 PM
To: Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>>
Cc: Giridhar Mandyam <mandyam@qti.qualcomm.com<mailto:mandyam@qti.qualcomm.com>>; Jeremy O'Donoghue <jodonogh@qti.qualcomm.com<mailto:jodonogh@qti.qualcomm.com>>; cwt-reg-review@ietf.org<mailto:cwt-reg-review@ietf.org>; Ned Smith <ned.smith@intel.com<mailto:ned.smith@intel.com>>; Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com<mailto:ncamwing@cisco.com>>; Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com<mailto:kathleen.moriarty.ietf@gmail.com>>; rats-chairs <rats-chairs@ietf.org<mailto:rats-chairs@ietf.org>>
Subject: [EXTERNAL] Re: Registration of Entity Attestation Token claims in the CWT registry

Hi Mike,

I’m not trying grab anything here that we should not have.

The early allocation process, according to RFC 7120, is handled by the WG chairs. It is my understanding is that the RATS chairs followed this process and that number 10-18, 20 have early assignment. That’s why they are in the draft without “TBD”. Maybe the process wasn’t completed or there is some other confusion. I did not interact with IANA myself (but I did read 7120).

I think this needs to be resolved between the RATS chairs, designated experts and IANA. I am happy to adjust the draft when this gets resolved.

LL



On Jan 12, 2022, at 9:58 PM, Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> wrote:

Yours is not the first specification that’s tried to preallocate the rare single-byte claim numbers for claims not of general applicability.  At https://www.iana.org/assignments/cwt/cwt.xhtml, you’ll note that most of the claims allocated by draft-ietf-ace-oauth-authz are in the double-byte space because they’re not applicable to a wide variety of applications.  They were originally requested to be in the single-byte range and the designated experts negotiated with the editors to move their requested assignments.

Jim Schaad was always a stickler about specifications using TBD in their registration requests instead of assumed numbers.  At most, he would tolerate “TBD (requested assignment NNN)”.  Of course, he was right.  It’s up to IANA and the designated experts to make the assignments, particular of scarce resources, not the spec authors.

Therefore, please revise your specification to remove the current numbers and replace them with “TBD”.  At that point, it would be fine to make an early registration request.  The experts and IANA could likely get you permanent numbers at that point, probably within a matter of weeks.

If you do not want to go the early allocation route, the other option is to use numbers in the “less than -65536” space, which are designated as “Reserved for Private Use”.  You can use numbers in that space however you want for as long as you want – including for facilitating interop testing until permanent numbers are assigned.

I’m sorry this appears to have come as a surprise.  The designated experts are trying to ensure that the CWT Claims numbers are efficiently allocated to do the most good for the most applications.  I hope you’ll take this request in that spirit and choose one of the paths outlined above to quickly resolve this issue.

                                                       Best wishes,
                                                       -- Mike

From: Giridhar Mandyam <mandyam@qti.qualcomm.com<mailto:mandyam@qti.qualcomm.com>>
Sent: Wednesday, January 12, 2022 9:05 PM
To: Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>>; Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>>; Jeremy O'Donoghue <jodonogh@qti.qualcomm.com<mailto:jodonogh@qti.qualcomm.com>>
Cc: cwt-reg-review@ietf.org<mailto:cwt-reg-review@ietf.org>; Ned Smith <ned.smith@intel.com<mailto:ned.smith@intel.com>>; Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com<mailto:ncamwing@cisco.com>>; Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com<mailto:kathleen.moriarty.ietf@gmail.com>>; rats-chairs <rats-chairs@ietf.org<mailto:rats-chairs@ietf.org>>
Subject: [EXTERNAL] RE: Registration of Entity Attestation Token claims in the CWT registry

+ @Jeremy O'Donoghue<mailto:jodonogh@qti.qualcomm.com>

Ned, RATS Chairs,

We were assured by the RATS Chairs when we highlighted these values in Rev. -09 that they would be signed off for the registry.  This is one of the reasons why we did not try to accelerate Last Call during the first half of last year.  There was clearly a disconnect.  Can you check into why this occurred?

Mike,

We just put out an FDO update on the assumption that these claim values are set (https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-RD-v1.1-20211214/FIDO-device-onboard-spec-v1.1-rd-20211214.html).  We are planning a 2nd interop event during the next couple of months and we may have to put that off now.  Is this issue intractable?  Can the claims not be assigned to EAT?

Jeremy can comment on any GlobalPlatform dependencies.

-Giri

From: Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>>
Sent: Wednesday, January 12, 2022 8:18 PM
To: Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>>
Cc: Giridhar Mandyam <mandyam@qti.qualcomm.com<mailto:mandyam@qti.qualcomm.com>>; cwt-reg-review@ietf.org<mailto:cwt-reg-review@ietf.org>; Smith, Ned <ned.smith@intel.com<mailto:ned.smith@intel.com>>; Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com<mailto:ncamwing@cisco.com>>; Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com<mailto:kathleen.moriarty.ietf@gmail.com>>
Subject: Re: Registration of Entity Attestation Token claims in the CWT registry

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
A couple more comments.

I know what you mean about taking the numbers <24. Not trying to be a hog or anything. It seems nobody, myself included, thought about it when this was done a year ago.

I know that Arm has SW that uses these assignments (ask Hannes and Thomas F). I think FIDO does too. I think there would be objections to a re assignment.

LL


On Jan 12, 2022, at 7:52 PM, Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>> wrote:

+ RATS chairs

Hi Mike,

The claims key numbers 10-18, 20 are early assignments by IANA. I didn’t handle the interaction with IANA, but I understand this to be true.  Changing them now would undermine some implementations that are using them.

LL



On Jan 12, 2022, at 6:11 PM, Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> wrote:

Please change the proposed CWT claim values for claims UEID through Submodules Section from 11 through 20 to 41 through 50 so that they are not using up most of the rare single-byte claim numbers.  Only claims that are of general applicability across multiple kinds of applications should be allocated in that space.

The one exception I would consider is the Location claim, which could be of general applicability.  If you believe that this location representation will be used by multiple kinds of applications, I would be willing to consider registering it in the single-byte claim space.

                                                       -- Mike

From: Cwt-reg-review <cwt-reg-review-bounces@ietf.org<mailto:cwt-reg-review-bounces@ietf.org>> On Behalf Of Giridhar Mandyam
Sent: Saturday, October 16, 2021 4:11 PM
To: cwt-reg-review@ietf.org<mailto:cwt-reg-review@ietf.org>
Cc: Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>>
Subject: [Cwt-reg-review] Registration of Entity Attestation Token claims in the CWT registry

To the CWT claims registry designated experts:

I am contacting you on behalf of the editors of the Entity Attestation Token specification (latest draft available athttps://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-10).  This is a standards-track document in the IETF Remote Attestation Procedures (RATS) Working Group.

Please note the requests for CWT registry of the claims outlined in https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-10#section-7.3.1.  We would like these claim values reflected in the IANA CWT registry as soon as possible.  Would this be possible?

Please contact myself Giri Mandyam or Laurence Lundblade (cc’ed) for further information if required.

Thanks

-Giri Mandyam

--- Begin Message ---
Hi Ned,

I believe I’ve addressed what you’ve requested. It’s checked in to the GitHub in this PR and I’ve made a PDF of it and attached it.

The descriptions of the claims for early assignment are in the -06 draft. There has been no change to these claims since it was published. The only thing new for these claims is the claim keys and the proposal for early assignment.

Note that the nonce is already registered for JWT, but not CWT. I’ve clarified that in the update.

Note also that this PR is against the current master which is a few pull requests (not related to the claims) ahead of the -06 draft.

LL




   On Jan 19, 2021, at 3:08 PM, Smith, Ned <ned.smith@intel.com<mailto:ned.smith@intel.com>> wrote:

   Laurance,
   Would it be possible to create a sub section in section 7.3 with the section heading “RFC Required” that includes only the code points that are to be allocated by IANA in advance of the draft completion?

   We will want to pay close attention to this section in terms of RFC changes that impact interoperability. Hence, having that section clearly identified is important.

   Also, please identify the actual values to be reserved by IANA registries without descriptive text preceding the expected text. For example (JWT Claim Name: Value requested is "ueid") can remove the text “Value requested is” can be removed.

   In case of the nonce claim, the request indicates the nonce claim is already made but an entry exists nevertheless. Possibly this doesn’t belong in the section titled “RFC Required” or if there is name collision but different semantics, possibly a different claim name should be used (aka rats-nonce)?

   Additionally, since section 7.2 indicates claims appear to be from within either or both JWT and CWT namespaces. It may be best to create separate sub-sections for both CWT and JWT namespace reservations (or something equivalent) that clearly indicates which value constitutes the allocation from which namespace.

   Finally, in order for the chairs to assess spec stability across the WG, it makes sense to generate a new editor’s copy (or working draft) that can be reviewed by other WG members easily – specifically related to the Section 7.3 … “RFC Required” sub-section.

   Thanks,
   Ned



   From: Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>>
   Date: Saturday, January 16, 2021 at 1:54 PM
   To: Nancy Cam-Winget <ncamwing@cisco.com<mailto:ncamwing@cisco.com>>
   Cc: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com<mailto:kathleen.moriarty.ietf@gmail.com>>, "Smith, Ned" <ned.smith@intel.com<mailto:ned.smith@intel.com>>, rats-chairs <rats-chairs@ietf.org<mailto:rats-chairs@ietf.org>>, Giridhar Mandyam <mandyam@qti.qualcomm.com<mailto:mandyam@qti.qualcomm.com>>
   Subject: Re: RATS CHAIRS PLEASE RESPOND -- IANA Early Allocation of Claim Keys

   I’ve got a pull request <https://github.com/ietf-rats-wg/eat/pull/90> ready now with the preassigned values added to the IANA section. We can merge it and publish a new draft if that will help.

   Do you mind if I contact Roman on this directly to get this moving?

   Thanks

   LL




      On Jan 10, 2021, at 2:10 PM, Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com<mailto:ncamwing@cisco.com>> wrote:

      Hi Laurence,
      I need to catch up on the latest EAT draft, but I don’t recall these being placed in the IANA request section of the draft?  I think we’ll need to have some reference to these and mark the request as TBD (not sure if you want the specific values you list below but those will need to be requested nonetheless).  I need to took at the latest EAT draft version as well as the CWT procedures as we likely need to cross that request with the ACE (and maybe COSE?) wgs….

      I’ve got some higher priority items to do at work this week, but will try to get to this in the next few days….unless the other co-chairs can help too.

      Best, Nancy

      From: Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>>
      Date: Saturday, January 9, 2021 at 11:28 AM
      To: ncamwing <ncamwing@cisco.com<mailto:ncamwing@cisco.com>>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com<mailto:kathleen.moriarty.ietf@gmail.com>>, "Smith, Ned" <ned.smith@intel.com<mailto:ned.smith@intel.com>>
      Cc: rats-chairs <rats-chairs@ietf.org<mailto:rats-chairs@ietf.org>>
      Subject: RATS CHAIRS PLEASE RESPOND -- IANA Early Allocation of Claim Keys
      Resent-From: <alias-bounces@ietf.org<mailto:alias-bounces@ietf.org>>
      Resent-To: ncamwing <ncamwing@cisco.com<mailto:ncamwing@cisco.com>>, <Kathleen.Moriarty.ietf@gmail.com<mailto:Kathleen.Moriarty.ietf@gmail.com>>, <ned.smith@intel.com<mailto:ned.smith@intel.com>>
      Resent-Date: Saturday, January 9, 2021 at 11:28 AM

      Hi Chairs,

      Sorry for the all-caps. Don’t mean to shout. Just wanted to make sure you see this as we haven’t heard a response from you after several requests (maybe the emails are getting lost?)

      There are several companies and groups (Google, ARM, FIDO and GP) working on EAT implementations. Early allocation of claim keys would be very beneficial.

      As I say below, the RFC 7120 procedure is for the WG chairs to take the next step of forwarding the request to the AD.

      I don’t mean to make a fuss, but If I don’t hear from you soon, I will contact Roman myself to try to move this forward.

      Thanks, LL







         Begin forwarded message:

         From: Giridhar Mandyam <mandyam@qti.qualcomm.com<mailto:mandyam@qti.qualcomm.com>>
         Subject: RE: [Rats] challenges of building dependant specifications against Internet-Drafts -- a way forward for EAT
         Date: December 18, 2020 at 1:28:41 PM PST
         To: Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>>, rats-chairs <rats-chairs@ietf.org<mailto:rats-chairs@ietf.org>>
         Cc: Bram Bonné <bbn@google.com<mailto:bbn@google.com>>

         Hi Chairs,

         Can we get guidance on the way forward?

         FIDO, GP, ARM and Google all have dependencies.

         -Giri

         From: Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>>
         Sent: Monday, December 14, 2020 11:17 AM
         To: rats-chairs <rats-chairs@ietf.org<mailto:rats-chairs@ietf.org>>
         Cc: Giridhar Mandyam <mandyam@qti.qualcomm.com<mailto:mandyam@qti.qualcomm.com>>; Bram Bonné <bbn@google.com<mailto:bbn@google.com>>
         Subject: Fwd: [Rats] challenges of building dependant specifications against Internet-Drafts -- a way forward for EAT

         CAUTION: This email originated from outside of the organization.
         Hi WG chairs, according to RFC 7120<https://tools.ietf.org/html/rfc7120#section-3>, the ball is in your court on this.  It’s up to you to make the call that we have consensus and forward to the AD for the next step.

         It looks to me like we have consensus. Qualcomm/FIDO, ARM and the primary authors have affirmed and there are no objections.

         It would be nice to push this quickly because of Google’s implementation which is on a short time line.

         Can you take the next step and forward it to the AD? I am also happy to do that myself if you want, but I think you would have to at least give a nod to the AD that you are OK with this.

         Thanks,

         LL






            Begin forwarded message:

            From: Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>>
            Subject: Re: [Rats] challenges of building dependant specifications against Internet-Drafts -- a way forward for EAT
            Date: December 4, 2020 at 11:57:02 AM PST
            To: Michael Richardson <mcr+ietf@sandelman.ca<mailto:mcr+ietf@sandelman.ca>>, "Nancy Cam-Winget (ncamwing)" <ncamwing=40cisco.com@dmarc.ietf.org<mailto:ncamwing=40cisco.com@dmarc.ietf.org>>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com<mailto:kathleen.moriarty.ietf@gmail.com>>, "Smith, Ned" <ned.smith@intel.com<mailto:ned.smith@intel.com>>
            Cc: "rats@ietf.org<mailto:rats@ietf.org>" <rats@ietf.org<mailto:rats@ietf.org>>

            So I read RFC 7120 which is super clear and exactly what is needed. It lines up with my third proposal. We will ask IANA to pre-register claims in the Standards Action space of the CWT registry and also in the JWT registry. Or rather per the 7120, the WG chairs determine consensus here, then will ask the AD(s) and then ask IANA.

            Is there consensus on pre-registration of these?

            Name      Description         CWT     JWT                     Type
            nonce     Nonce               10      <already registered>    byte string
            ueid      Universal Entity ID 11      ueid                    byte string
            oemid     OEM ID              13      oemid                   byte string
            seclevel  Security Level      14      seclevel                integer
            secboot   Secure boot         15      secboot                 integer
            dbgstat   Debug status        16      dbgstat                 integer
            location  Location            17      location                map
            submods   Submodules Section  20      submods                 map

            These have all been in the EAT document for a long time and are described well in draft-ietf-rats-eat-06. They are fairly well understood and have either no open issues or only small open issues in GitHub against them. They include the most essential claims (nonce, ueid, oemid & submods) to implement an EAT.

            I have chosen not to ask for the others because I don’t think they are as essential or as well understood yet and thus don’t meet the criteria in RFC 7120.

            CWT numbers aren’t contiguous so as to line up with examples that have been in the EAT draft for a while. I’ve shortened the JWT claims keys to less than 8 per RFC 7519.

            If approved and registered, we’ll quickly publish a new EAT draft.

            LL









               On Nov 30, 2020, at 3:16 PM, Michael Richardson <mcr+ietf@sandelman.ca<mailto:mcr+ietf@sandelman.ca>> wrote:


               Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>> wrote:





                  The trouble is that I think many claims should be in the Standards
                  Action range (-255 to 255).  For example, nonce, ueid, submods section,
                  location, CoSWID and probably a few others should be in the standard
                  space. If I were IANA I would hesitate to register these in the
                  Standards Action range until the EAT document is further along.


               The WG can ask for Early Allocation.
               It should do it immediately, so that the Expert will provided feedback immediately.






                  It also seems poor practice to unilaterally pre-assign Standards Action
                  range claims in an EAT draft and then use them in a bunch of
                  implementations. Those numbers could be assigned to some one else
                  before EAT is an RFC.


               You can do that if a registry you are just creating.
               But, yes, you can't do that if you are using CWT.






                  Register them in the Specification Required space (255 to 65535) once
                  and for all. That will result in 3-byte map labels rather than 1-byte
                  map labels, but there’s no transition.





                  Finally, a third proposal:





                  Maybe we can convince IANA to pre-register a small clear set in the
                  standard space? Perhaps just nonce and UEID.


               Please go read RFC7120.

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

               _______________________________________________
               RATS mailing list
               RATS@ietf.org<mailto:RATS@ietf.org>
               https://www.ietf.org/mailman/listinfo/rats


            _______________________________________________
            RATS mailing list
            RATS@ietf.org<mailto:RATS@ietf.org>
            https://www.ietf.org/mailman/listinfo/rats


--- End Message ---