Re: [Rats] IANA pre-RFC code points

Laurence Lundblade <lgl@island-resort.com> Wed, 17 February 2021 00:59 UTC

Return-Path: <lgl@island-resort.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 C2F2B3A112D for <rats@ietfa.amsl.com>; Tue, 16 Feb 2021 16:59:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 idmVzDWsI0aW for <rats@ietfa.amsl.com>; Tue, 16 Feb 2021 16:59:25 -0800 (PST)
Received: from p3plsmtpa12-07.prod.phx3.secureserver.net (p3plsmtpa12-07.prod.phx3.secureserver.net [68.178.252.236]) (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 E89693A09B7 for <rats@ietf.org>; Tue, 16 Feb 2021 16:59:24 -0800 (PST)
Received: from laurences-mbp.gateway.2wire.net ([187.223.244.101]) by :SMTPAUTH: with ESMTPSA id CBBalwBVBI3CoCBBblTe4P; Tue, 16 Feb 2021 17:59:24 -0700
X-CMAE-Analysis: v=2.4 cv=ZPYSJV3b c=1 sm=1 tr=0 ts=602c6a6c a=4DuQCvq92BI7+Z+mmVs66w==:117 a=4DuQCvq92BI7+Z+mmVs66w==:17 a=IkcTkHD0fZMA:10 a=7CQSdrXTAAAA:8 a=K6EGIJCdAAAA:8 a=lKIKd7NtAAAA:8 a=NyqR58hf5oxTFHBywucA:9 a=QEXdDO2ut3YA:10 a=a-qgeE7W1pNrGK8U0ZQC:22 a=L6pVIi0Kn1GYQfi8-iRI:22 a=Q4nn7pJknIVYsolpXXmV:22
X-SECURESERVER-ACCT: lgl@island-resort.com
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Laurence Lundblade <lgl@island-resort.com>
In-Reply-To: <79A5E862-B336-4B67-AE02-9E6F2E9375AC@arm.com>
Date: Tue, 16 Feb 2021 17:59:21 -0700
Cc: "Smith, Ned" <ned.smith@intel.com>, "rats@ietf.org" <rats@ietf.org>, Simon Frost <Simon.Frost@arm.com>, Adrian Shaw <Adrian.Shaw@arm.com>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B34C7BD7-6EE7-4948-911F-F1F92FAB3954@island-resort.com>
References: <80F4DFAD-8A5D-44DC-BEDF-BA96B7F21991@arm.com> <D7AFAA80-B8EE-4657-8A81-71FE4F79E23B@island-resort.com> <CO1PR11MB51690D5D3D7EA17153C83EBAE5889@CO1PR11MB5169.namprd11.prod.outlook.com> <B549435F-1896-4A8D-A1FB-CE57567E824D@island-resort.com> <0CF448FE-B249-496E-B1A8-528B189DA16C@intel.com> <E386083F-DD06-452D-A6A7-6EEC0C79A1F8@island-resort.com> <DC3C69C6-4995-4050-B8E0-38057B321DE7@arm.com> <AC5754A8-1BC3-49E9-8B61-F7DA96BDDA99@island-resort.com> <79A5E862-B336-4B67-AE02-9E6F2E9375AC@arm.com>
To: Thomas Fossati <Thomas.Fossati@arm.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-CMAE-Envelope: MS4xfDrIhP5wC/RzkDDQ/1AufaKwVYPFsFK9veUKiaammzjKL2r9VORIeqXxyp03Sy8Xx2HkLbz8fyy66b3FeViHr5MRvoLnGkdBja7IamDG12infEDOktHF rKJXuppJCdkumYIqu6L+bwynhdPV3DCPgeCNxEY+lTSl4b1bUkTnsVnsKTAOxNh5t5DsQEQGxwI+S77UJmMv9bPngt8q0AiBVNF3HyjvOCO58pPkiuBJC5mB tf0CXATAbT6ultSFQ73xmbE0jbR5af3qyqTfmDhiibhmX1yh+yKt/zu2CB//EQ+PpVXciBXpRaqGSZuU14Sj2YWRrdopZbsRe2NHnYTddiZsvqkuQ3eUOHkp XWp//vZs0OxDJ/0XT1NvfwWyhZaWwg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/p_4ApnugN0HrlR4OLNTkUMOODvY>
Subject: Re: [Rats] IANA pre-RFC code points
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: Wed, 17 Feb 2021 00:59:27 -0000


> On Feb 16, 2021, at 5:44 PM, Thomas Fossati <Thomas.Fossati@arm.com> wrote:
> 
> On 16/02/2021, 20:25, "Laurence Lundblade" <lgl@island-resort.com> wrote:
>> Below...
>> 
>>> On Feb 16, 2021, at 11:10 AM, <Thomas.Fossati@arm.com> wrote:
>>> 
>>> On 16/02/2021, 17:43, <lgl@island-resort.com> wrote:
>>>> 
>>>> If we can agree that profiles are necessary and that a simple text
>>>> string is good enough to name a profile, then we can put in in the
>>>> pre-allocation.  We don't have to agree on the mechanism for
>>>> defining profiles, just for naming them.
>>> 
>>> I think what is in -08 in terms of defining a profile is great.
>>> 
>>> I think we should just nail down the type and constraints around the
>>> claim value.  The way it is now (i.e., plain, unstructured tstr)
>>> creates an incentive to using short strings and therefore increasing
>>> the chance of collisions, which is bad.
>>> 
>>> If we say:
>>> ~~~
>>> profile-claim = ( profile => $profile-type,)
>>> 
>>> $profile-type /= uri ; i.e., #6.32(tstr)
>>> $profile-type /= oid ; draft-ietf-cbor-tags-oid
>>> ~~~
>>> 
>>> We'd allow both human readable https://fidoalliance.org/profile/a,
>>> as well as compact, machine readable 1.3.6.1.4.1.etc in a way that
>>> prevents clashes.
>>> 
>>> I don't think it's crazy to expect the profile owner to also control
>>> a DNS name and/or a PEN.
>> 
>> Yes, I was thinking we might want this to be a URI or such myself.
>> Here’s several options:
>> 
>> 1) Make it string-or-uri like the JWT issuer, subject and audience
>>   claims. Already well-established approach.
>> 
>> 2) Allow string, URI or OID. Most flexibility, but do we really need
>>   OIDs?
> 
> I like OIDs because they are relatively compact and unambiguous. They
> look like the CBOR-friendly equivalent of URIs.  They also render well
> in JSON as strings in dotted notation.

I think a good very compact CBOR-friendly way would be to use a simple integer in some way.

One way to do that is to make an IANA registry for profiles with each entry:
  - integer
  - name
  - URI

The profile claim in a token could be solely the integer value. Or it could be the URI or the text string. 

I’d prefer that to more use of OIDs.

The policy for the registry would be pretty loose. Just indicate the existence of some document somewhere. Maybe reserve the values less than 24 for profiles documents that are standards.

This seems pretty good to me, but I’m a bit worried about delaying the pre-allocation for it since it involves creating another IANA registry.

LL