Re: [Rats] IANA pre-RFC code points

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Wed, 17 February 2021 10:06 UTC

Return-Path: <henk.birkholz@sit.fraunhofer.de>
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 170B53A18B9 for <rats@ietfa.amsl.com>; Wed, 17 Feb 2021 02:06:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 FggWblnpyIq7 for <rats@ietfa.amsl.com>; Wed, 17 Feb 2021 02:06:50 -0800 (PST)
Received: from mail-edgeKA24.fraunhofer.de (mail-edgeka24.fraunhofer.de [153.96.1.24]) (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 4AC733A18B8 for <rats@ietf.org>; Wed, 17 Feb 2021 02:06:48 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FGCwDz6Sxg/xoBYJliHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU8CgXqBJYFBCgGENokEiCEtA5pfgV8JCwEBAQEBAQEBAQk?= =?us-ascii?q?dCwoCBAEBA4RKAoINASU4EwIQAQEGAQEBAQEGBAIChk4NQxYBgnuBCAEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEWAgg5GToSAQEeAQEBAwEBDBUPAQUtCQIJEAsYAgI?= =?us-ascii?q?mAgInIBAGAQwBBQIBAYJsAYMFBQu3DoEyhViDSYE+BoEOKoZ9glGCeHomEIF?= =?us-ascii?q?NQSZrJw+CZD6CXQEBgSoBEgFNgmqCXwSBZWkqKwcBA0MQWygWNpEZCIMLQId?= =?us-ascii?q?snTwsB4FrgRKBGQULiBCMNIYUBQofgzE7ig2FQQaPb5Q7iy6ReoR+gWyBC3B?= =?us-ascii?q?NJE+CaVAXAg2OKxeBAgECCodThUZyNwIGAQkBAQMJfIYZg28BgQ4BAQ?=
X-IPAS-Result: =?us-ascii?q?A2FGCwDz6Sxg/xoBYJliHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?U8CgXqBJYFBCgGENokEiCEtA5pfgV8JCwEBAQEBAQEBAQkdCwoCBAEBA4RKA?= =?us-ascii?q?oINASU4EwIQAQEGAQEBAQEGBAIChk4NQxYBgnuBCAEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEWAgg5GToSAQEeAQEBAwEBDBUPAQUtCQIJEAsYAgImAgInIBAGAQwBB?= =?us-ascii?q?QIBAYJsAYMFBQu3DoEyhViDSYE+BoEOKoZ9glGCeHomEIFNQSZrJw+CZD6CX?= =?us-ascii?q?QEBgSoBEgFNgmqCXwSBZWkqKwcBA0MQWygWNpEZCIMLQIdsnTwsB4FrgRKBG?= =?us-ascii?q?QULiBCMNIYUBQofgzE7ig2FQQaPb5Q7iy6ReoR+gWyBC3BNJE+CaVAXAg2OK?= =?us-ascii?q?xeBAgECCodThUZyNwIGAQkBAQMJfIYZg28BgQ4BAQ?=
X-IronPort-AV: E=Sophos;i="5.81,184,1610406000"; d="scan'208";a="29252516"
Received: from mail-mtaka26.fraunhofer.de ([153.96.1.26]) by mail-edgeKA24.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Feb 2021 11:06:45 +0100
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFEQDz6Sxg/wpIDI1iHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU8CgXovdlk3MQoBhDaJBIghLQOaX4FoCwEDAQEBAQEJHQs?= =?us-ascii?q?KAgQBAYRNAoILAiU4EwIQAQEFAQEBAgEGBHGFYQ1DFgGFawEBBAEBDBUPAQU?= =?us-ascii?q?tCQIJEAsYAgImAgInIBAGAQwBBQIBAYJsAYMKC7cOgTKFWINJgT4GgQ4qhn2?= =?us-ascii?q?CUYJ4eiYQgU1BJmsnD4JkPoJdAQGBKgESAU2CaoJfBIFlaSorBwEDQxBbKBY?= =?us-ascii?q?2kRkIgwtAh2ydPCwHgWuBEoEZBQuIEIw0hhQFCh+DMTuKDYVBBo9vlDuLLpF?= =?us-ascii?q?6hH6BbCNncE0kT4JpUBcCDY4rF4ECAQIKh1OFRkIwNwIGAQkBAQMJfIYZg28?= =?us-ascii?q?BgQ4BAQ?=
X-IronPort-AV: E=Sophos;i="5.81,184,1610406000"; d="scan'208";a="106360324"
Received: from ksapp01.sit.fraunhofer.de ([141.12.72.10]) by mail-mtaKA26.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Feb 2021 11:06:43 +0100
Received: from ksapp01.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by ksapp01.sit.fraunhofer.de (Postfix) with ESMTPS id C4E5280230; Wed, 17 Feb 2021 11:06:42 +0100 (CET)
Received: from [192.168.16.50] (79.234.113.123) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 17 Feb 2021 11:06:42 +0100
To: Thomas Fossati <Thomas.Fossati@arm.com>, Laurence Lundblade <lgl@island-resort.com>
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>
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> <B34C7BD7-6EE7-4948-911F-F1F92FAB3954@island-resort.com> <4473BF8F-2681-4F0B-8152-2194F23A12CE@arm.com>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <7b79459f-b766-d821-e549-7b3068760a10@sit.fraunhofer.de>
Date: Wed, 17 Feb 2021 11:06:40 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <4473BF8F-2681-4F0B-8152-2194F23A12CE@arm.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [79.234.113.123]
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/YSeidjWMhpNbwtI4UPhJm4MldIc>
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 10:06:54 -0000

+ 1 to:

* oids as a preferred choice (uri are fine but alas not very concise)
* avoiding unstructured text (and inheriting that weirdness here)
* avoiding more registries (not only because of more delay)

On 17.02.21 10:55, Thomas Fossati wrote:
> Hi Laurence,
> 
> On 17/02/2021, 00:59, "Laurence Lundblade" <lgl@island-resort.com> wrote:
>>> 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
> 
> Yes, but we'd need another registry.  Going with URIs and OIDs (PENs)
> would avoid the extra IANA round-trip.
> 
>> 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.
> 
> I am not married to any particular format, I am looking for one that can
> effectively balance:
> * compactness of representation
> * minimal IANA impact
> * collision avoidance of the identifiers
> 
>> 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.
> 
> yep
> 
> cheers, t
> 
> 
> 
> 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.
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
>