Re: [Rats] IANA pre-RFC code points

Laurence Lundblade <> Mon, 15 February 2021 20:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 569D03A110A for <>; Mon, 15 Feb 2021 12:36:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.004
X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bipTcbwpUEUX for <>; Mon, 15 Feb 2021 12:36:36 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF1343A1106 for <>; Mon, 15 Feb 2021 12:36:36 -0800 (PST)
Received: from ([]) by :SMTPAUTH: with ESMTPSA id BkbhlHjKbyyAdBkbilvHec; Mon, 15 Feb 2021 13:36:35 -0700
X-CMAE-Analysis: v=2.4 cv=LIyj/La9 c=1 sm=1 tr=0 ts=602adb53 a=d0Q/S/h1eWzhy871yZ6y/w==:117 a=d0Q/S/h1eWzhy871yZ6y/w==:17 a=48vgC7mUAAAA:8 a=QyXUC8HyAAAA:8 a=K6EGIJCdAAAA:8 a=7CQSdrXTAAAA:8 a=W5AKkGqC2wzW0sjNLUUA:9 a=7fiJSp3esupyk1j9:21 a=C3wQSsGipDHNpXb4:21 a=QEXdDO2ut3YA:10 a=KwTcI9cXVM7TelbpIOkA:9 a=83TKuLlF-RqHBO-C:21 a=zZfpmgPaK06_Z171:21 a=xC7rDOlB603dKlBd:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=L6pVIi0Kn1GYQfi8-iRI:22 a=a-qgeE7W1pNrGK8U0ZQC:22
From: Laurence Lundblade <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_805C5479-210E-4743-BC41-5E9EC0276FC4"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Mon, 15 Feb 2021 13:36:33 -0700
In-Reply-To: <>
Cc: Thomas Fossati <>, "" <>, Adrian Shaw <>, Hannes Tschofenig <>, Simon Frost <>
To: "Smith, Ned" <>
References: <> <> <>
X-Mailer: Apple Mail (2.3608.
X-CMAE-Envelope: MS4xfMiPRLqGy4Im/RQGvMqmeau4nrVBqAaNJv0f2hOCCiWnLZSdY7tm/6QdXFnTh4K6sR6xVxxKYWZdvY6Cq3J8Egy71bFzJ1e+IFFL37frffkbu4hud+5a xEc5VRJwQm4iadGObkOm/FNRf6hXQINArIIIt789d66ij0kCLC+MMk1Y2ICDwbeAdetiW39GY3V897fjUOIFfR1qX3cPNJBFe3D+Chw9/bxrfAuzTKxmwcBl XLPK5XfXci9ohDEdktOp/ZZrYUdbfLv5BIomS70zoMhJRsKAbUjHzsl1XhKkVIz4k8ERf2t/DfbY46d/St5KqYjSECt3Os1siojUVGPdv0xyqR6AMoC55SgV tXRHbrFqttSCtXaU34Gsm8qQg4mg5Q==
Archived-At: <>
Subject: Re: [Rats] IANA pre-RFC code points
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Feb 2021 20:36:38 -0000

They are largely complementary mechanisms.  Maybe you could call the IANA claims registry the palette of colors and a profile the painting.

The IANA claims registry describes lots of different claims. Some implementations will use one set of them, other implementations will use others. Some will use proprietary claims that are not in the registry. This however doesn’t give much guarantee of interoperability between an Attester and Verifier.

A profile says which claims are in use for a give use case. It says which claims are prohibited, which are required and which are optional. It should be complete enough to give full interoperability for a use case.

A profile also says which crypto, which serialization format and such to use so that interoperability can be achieved.  There are 12 separate things that a profile should specify (e.g., required claims, prohibited claims, JSON/CBOR, algorithms, CBOR serialization, endorsement identification…). Take a look at the text here <>.


> On Feb 15, 2021, at 12:36 PM, Smith, Ned <> wrote:
> The topic of how vendor specific data should be handled has been brought up in the past. The conversation seemed to reach consensus by using the CWT/JWT existing mechanisms for vendor specific tags. Maybe someone should summarize how the profile mechanism compares to CWT/JWT vendor specific mechanisms?
> Ned Smith - Intel -
> ________________________________________
> From: Laurence Lundblade <>
> Sent: Saturday, February 13, 2021 3:00 PM
> To: Thomas Fossati
> Cc: Smith, Ned;; Adrian Shaw; Hannes Tschofenig; Simon Frost
> Subject: Re: [Rats] IANA pre-RFC code points
> Profiles and are only in EAT drafts from the last month so they haven’t had much review or discussion. That makes them different from the other claims for which pre-assignment is requested.  I don’t think I have even presented them in detail in any meetings. So personally I am kind of on the fence about this.
> A thorough reading and commenting by folks other than Arm would get me off the fence.
> Happy to hear what the chairs think too.
> LL
> On Feb 12, 2021, at 11:14 AM, Thomas Fossati <<>> wrote:
> It'd be extremely useful to us if the "profile" claim could be added to
> the list early assignments.
> That way the PSA token would just use the standard code point assigned
> to "profile" to create the context to interpret the rest of the private
> PSA claims - which means we would not need to make any further request
> to IANA.
> Hopefully it is not too late to ask :-)
> Cheers!