Re: [Rats] Vetting claim definitions

Hannes Tschofenig <Hannes.Tschofenig@arm.com> Fri, 07 June 2019 11:28 UTC

Return-Path: <Hannes.Tschofenig@arm.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 62ABE12008A for <rats@ietfa.amsl.com>; Fri, 7 Jun 2019 04:28:54 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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=armh.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 aiutbM66RL10 for <rats@ietfa.amsl.com>; Fri, 7 Jun 2019 04:28:50 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130078.outbound.protection.outlook.com [40.107.13.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB4812001A for <rats@ietf.org>; Fri, 7 Jun 2019 04:28:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JU1Cq4Z+caV6NmrubYQLQvVfcqRxz5b+UaDmN0zjnO4=; b=HxoA4v3+7/XGyGuHDzoHutTLy/uQghSwI0lOLHEme6ntyvJxgRaGXu8Y3z4OQFfc/sJu5m/kQhdTLL8PZEAza3v1x2UcibLAv9uZBB7WyZ8aYSbpr3u1/xemRfj/ZseIOVnduQgchLhUVXFsSmTglqUOW75wOa8Nr0oa/CU3umQ=
Received: from VI1PR08MB5360.eurprd08.prod.outlook.com (52.133.244.88) by VI1PR08MB3040.eurprd08.prod.outlook.com (52.133.14.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.22; Fri, 7 Jun 2019 11:28:46 +0000
Received: from VI1PR08MB5360.eurprd08.prod.outlook.com ([fe80::4014:31c8:2ea3:7afd]) by VI1PR08MB5360.eurprd08.prod.outlook.com ([fe80::4014:31c8:2ea3:7afd%2]) with mapi id 15.20.1965.011; Fri, 7 Jun 2019 11:28:46 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>, Laurence Lundblade <lgl@island-resort.com>, Michael Richardson <mcr+ietf@sandelman.ca>
CC: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] Vetting claim definitions
Thread-Index: AQHVGxAckwBFHzwCtkGJuRwO7P2ipaaNCI4AgAAs8gCAAB0/AIAAC71w
Date: Fri, 07 Jun 2019 11:28:46 +0000
Message-ID: <VI1PR08MB536061869B7BE623F861B821FA100@VI1PR08MB5360.eurprd08.prod.outlook.com>
References: <BC6D5D3A-BD2F-496E-AA68-D2A758A33843@island-resort.com> <12913.1559739926@localhost> <30754CD8-98AB-4080-952E-880BC630EC69@island-resort.com> <BL0PR00MB029274A33B44A0B8CE310C0BF5160@BL0PR00MB0292.namprd00.prod.outlook.com>
In-Reply-To: <BL0PR00MB029274A33B44A0B8CE310C0BF5160@BL0PR00MB0292.namprd00.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=b1ecc555-a57b-4de2-ba4c-0000e243b876; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; 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_SetDate=2019-06-05T17:28:48-0800; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
x-ts-tracking-id: 5393488c-8c30-4e44-b992-8bff2a39479f.1
x-checkrecipientchecked: true
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com;
x-originating-ip: [217.140.96.140]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: af9cbbe3-72db-4b38-1d47-08d6eb3b4e39
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:VI1PR08MB3040;
x-ms-traffictypediagnostic: VI1PR08MB3040:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <VI1PR08MB304005982EFC935E2BCAC96EFA100@VI1PR08MB3040.eurprd08.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0061C35778
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(346002)(366004)(376002)(396003)(124014002)(199004)(189003)(40434004)(66556008)(229853002)(66476007)(76116006)(52536014)(73956011)(64756008)(53936002)(71200400001)(66066001)(606006)(2906002)(33656002)(5660300002)(110136005)(99286004)(478600001)(486006)(6116002)(54896002)(66446008)(476003)(26005)(236005)(81156014)(8676002)(81166006)(68736007)(316002)(25786009)(76176011)(966005)(3846002)(86362001)(4326008)(55016002)(5024004)(6246003)(6306002)(14444005)(74316002)(6436002)(256004)(6506007)(102836004)(790700001)(53546011)(446003)(45080400002)(71190400001)(14454004)(11346002)(8936002)(72206003)(9686003)(7736002)(7696005)(186003)(66946007); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR08MB3040; H:VI1PR08MB5360.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Q8yhSvm8L2se+BgPUt843ONUhnPMIuohHyTLmSdiTSN1+FcRHsrS0J3HVyTDSCPoUebdiGesl4t7DN5BYCc5XRUbKZiL6i236U7zXdl2T5as5dIwlxS1JQsYqiIBxQ7UmJL9Km1XzcmWEAP7h+UmLPrKourA15p75hB2+MDlBX3dfDkI1gLI30+sglbKoi9BmNiLl54mKP/FGshSJaTZIbbTmX/Dpl7vYR7w/OpgkdrJeF9HA6DXOoEVeEPypNEdvMRtG7ez6M3GRnCvoUbLQ4HhDSLA9bWWXiNvimw7GSbHX2ijgG+X2mragS+TDfq6WOnYnN2wAr6m9+PXR0ndXT4cPFi+KKH9gR830itwa6fKKN0RVdlJG0pUScziiKPRsLhOkUKAoN6SSqS14IjECMJswrHTbGkjkwEQw4WEpyE=
Content-Type: multipart/alternative; boundary="_000_VI1PR08MB536061869B7BE623F861B821FA100VI1PR08MB5360eurp_"
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: af9cbbe3-72db-4b38-1d47-08d6eb3b4e39
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2019 11:28:46.6256 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Hannes.Tschofenig@arm.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3040
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/yUjipOF4Bd-423BdoytRPzjBJK0>
Subject: Re: [Rats] Vetting claim definitions
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, 07 Jun 2019 11:28:54 -0000

FWIW: While the JWT registry looks more mixed in terms of claim types. This is, however, only a result of the widespread adoption.
There are no problems, as far as I know, with the diversity of the claims and that they are not all useful in every context. Different deployments use the claims they find useful.

I am wondering whether we are trying to fix a problem with the registry of claims that doesn’t occur in practice.

Ciao
Hannes

From: RATS <rats-bounces@ietf.org> On Behalf Of Mike Jones
Sent: Mittwoch, 5. Juni 2019 19:31
To: Laurence Lundblade <lgl@island-resort.com>; Michael Richardson <mcr+ietf@sandelman.ca>
Cc: rats@ietf.org
Subject: Re: [Rats] Vetting claim definitions

Actually, normal (non-collision-resistant) JWT claims *are* allocated on a specification required basis with expert review.  See this text at https://tools.ietf.org/html/rfc7519#section-10.1:

   Values are registered on a Specification Required [RFC5226<https://tools.ietf.org/html/rfc5226>] basis
   after a three-week review period on the jwt-reg-review@ietf.org<mailto:jwt-reg-review@ietf.org>
   mailing list, on the advice of one or more Designated Experts.
   However, to allow for the allocation of values prior to publication,
   the Designated Experts may approve registration once they are
   satisfied that such a specification will be published.

So a specification can easily register both JWT and CWT claims.

                                                       -- Mike

From: Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>>
Sent: Wednesday, June 5, 2019 8:46 AM
To: Michael Richardson <mcr+ietf@sandelman.ca<mailto:mcr+ietf@sandelman.ca>>
Cc: rats@ietf.org<mailto:rats@ietf.org>; Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>>
Subject: Re: [Rats] Vetting claim definitions

Below…
+ Mike Jones, co-author of CWT

On Jun 5, 2019, at 6:05 AM, Michael Richardson <mcr+ietf@sandelman.ca<mailto:mcr+ietf@sandelman.ca>> wrote:


Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>> wrote:
— Today CWT allocates millions of slots for expert review. No
specification is required, but some information should be provided.

JWT doesn’t seem to have this, which is maybe why it is messier. It
kind of seems bad and wrong that it doesn’t to me.

JWT doesn't have this because the claims are "unlimited" length strings, so
one can always make up a unique string in lieu of registration.
 org.island-resort.lgl.whateverstringyouwant

is probably completely yours :-)
Of course, if you want to interoperate you need to agree about how, so there
are some advantages of a forcing function that demands you write things down
first :-)

Unlimited length string claim names are fully part of CWT. Also, COSE allows them for headers, algorithm names and such too. So from a syntax view CWT and COSE are the same as JWT in allowing long string names.

However, COSE and CWT are different in the management of the string name space:

Strings of length 1            Standards Action
Strings of length 2            Specification Required
Strings of length greater than 2    Expert Review

These, along with the integer names space rules, then imply:

Integer values less than -65536 are the only ones free for use with no review or processing by IANA and experts.

JWT also has this notion of Collision-Resistant Name based on OIDs or UUIDs, which is essentially some rules to make up names that don’t go into an IANA registry and are still unique and won’t collide.

JWT could have done what CWT does. Seems to me that CWT has taken a radically more managed approach to the super-open JWT approach. Maybe the CWT folks realized the JWT design was poor.


At any rate, there seems to be some consensus here that the CWT approach is what we want for attestation. It is also the more recent and thus maybe more advanced thinking.

I’m hoping we can find our way to just accept the CWT claim naming management scheme as is for attestation. If other CWT-based efforts did the same (draft-birkholz-core-coid) did the same then the world would be much simpler.

However that still leaves open some issue with JWT namespace management. (We do want JSON based attestation to be JWT’s, right? Just the same as CBOR-based attestation are CWT’s).

LL

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.