IETF Logo Mail Archive

Re: [Rats] Profile identifier (was Re: EAT Profiles)

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 21 September 2022 21:42 UTC

Return-Path: <mcr@sandelman.ca>
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 59FBEC1524AE for <rats@ietfa.amsl.com>; Wed, 21 Sep 2022 14:42:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIeGvUxEaNNm for <rats@ietfa.amsl.com>; Wed, 21 Sep 2022 14:42:14 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C9D4C1522D2 for <rats@ietf.org>; Wed, 21 Sep 2022 14:42:14 -0700 (PDT)
Received: from dooku.sandelman.ca (dynamic-089-012-090-247.89.12.pool.telefonica.de [89.12.90.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 29ED81F4AF; Wed, 21 Sep 2022 21:42:13 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 83E651A01E6; Wed, 21 Sep 2022 23:41:12 +0200 (CEST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Giridhar Mandyam <mandyam@qti.qualcomm.com>, "Smith, Ned" <ned.smith@intel.com>, "rats@ietf.org" <rats@ietf.org>
In-reply-to: <2f371cdb-38b1-f042-27e7-86afb91a38a2@sit.fraunhofer.de>
References: <71934.1663019954@dooku> <DBBPR08MB5915AC23726BF997EB9E44C4FA489@DBBPR08MB5915.eurprd08.prod.outlook.com> <19805.1663344806@dooku> <AS8PR08MB5911DB2FE9608541698983B0FA4D9@AS8PR08MB5911.eurprd08.prod.outlook.com> <ab4312d3-c35f-5e72-9658-ca88ba3523c2@sit.fraunhofer.de> <CAObGJnNjuTT+QqnSpp1abrX-1hHGzCkVkzrM8GArPs8sDu=W+g@mail.gmail.com> <f9f289ad-5f36-b781-7502-219778148491@sit.fraunhofer.de> <885ABB6E-FD98-45E2-84BE-5A3A3C37D3F8@island-resort.com> <ABB7105F-6B5F-47AA-886C-8490024C3D47@intel.com> <46605.1663756035@dooku> <SJ0PR02MB835323B33E4FFA04DB96FECB814F9@SJ0PR02MB8353.namprd02.prod.outlook.com> <2f371cdb-38b1-f042-27e7-86afb91a38a2@sit.fraunhofer.de>
Comments: In-reply-to Henk Birkholz <henk.birkholz@sit.fraunhofer.de> message dated "Wed, 21 Sep 2022 16:00:57 +0200."
X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 27.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 21 Sep 2022 23:41:12 +0200
Message-ID: <180924.1663796472@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/BuYOG6ztcSDY6GMtLe75vDvOSBc>
Subject: Re: [Rats] Profile identifier (was Re: EAT Profiles)
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.39
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, 21 Sep 2022 21:42:15 -0000

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> wrote:
    > are you talking about the values of the profile claim (I am assuming
    > numbers for now) to be registered in an IANA registry or are you
    > talking about new claims defined by a profile specification to be
    > registered in the IANA CBOR Web Token (CWT) Claims registry? I am
    > really not sure anymore.

I'm talking about establishing an IANA Registry that would allow for which EAT
Profile is involved to be a small integer.  The other options (PEN-based OID,
and string) would also be accomodated.

In CBOR, each maps to a differently encoded object (Integer, byte-string,
text-string), so it's trivial to distinguish them.

In JSON, they would all be strings in the end, so there would have to be some
kind of pattern match to figure out which is which.  But, integers are easily
recognized.  If there is a ".", and only numbers, then it's an OID.
Otherwise, it's a URI.

This is a matter of two paragraphs in the IANA Considerations.
Not doing it likely will result in DISCUSSes in my opinion.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email