[Rats] Re: UCCS and EAT media types (was: Re: Re: AD follow-up review of draft-ietf-rats-uccs-09)

Carsten Bormann <cabo@tzi.org> Mon, 03 June 2024 15:09 UTC

Return-Path: <cabo@tzi.org>
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 C98E7C151980 for <rats@ietfa.amsl.com>; Mon, 3 Jun 2024 08:09:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.188
X-Spam-Level:
X-Spam-Status: No, score=-4.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 jBY42wvVR5nt for <rats@ietfa.amsl.com>; Mon, 3 Jun 2024 08:09:26 -0700 (PDT)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [134.102.50.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9CCBC14E515 for <rats@ietf.org>; Mon, 3 Jun 2024 08:09:25 -0700 (PDT)
Received: from eduroam-0016.wlan.uni-bremen.de (eduroam-0016.wlan.uni-bremen.de [134.102.16.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4VtHFH1P8hzDCh7; Mon, 3 Jun 2024 17:09:23 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CA+1=6ydAVSbKmphfiFiukv2m7tpkgsZ3RUsqcQW1QRZeMc9_qA@mail.gmail.com>
Date: Mon, 03 Jun 2024 17:09:22 +0200
X-Mao-Original-Outgoing-Id: 739120162.620785-a80bfd432d0366061ae64419ee1ebb4c
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E22DA74-DF3A-48ED-AC30-CCEFB4816A05@tzi.org>
References: <PH1P110MB1116C5BE031039613AA69302DC2DA@PH1P110MB1116.NAMP110.PROD.OUTLOOK.COM> <609017C0-5043-46A1-81B1-6835F4BD6FF9@tzi.org> <CA+1=6ydAVSbKmphfiFiukv2m7tpkgsZ3RUsqcQW1QRZeMc9_qA@mail.gmail.com>
To: "thomas.fossati@linaro.org" <thomas.fossati@linaro.org>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Message-ID-Hash: 5DCQAJ3WXYQE7OV5S3PJ3E5YRMKVDO7T
X-Message-ID-Hash: 5DCQAJ3WXYQE7OV5S3PJ3E5YRMKVDO7T
X-MailFrom: cabo@tzi.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rats.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Roman Danyliw <rdd@cert.org>, "rats@ietf.org" <rats@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Rats] Re: UCCS and EAT media types (was: Re: Re: AD follow-up review of draft-ietf-rats-uccs-09)
List-Id: Remote ATtestation procedureS <rats.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/x6ZlVGf2V3LJ4GV6kl_Sk5Y_8H4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Owner: <mailto:rats-owner@ietf.org>
List-Post: <mailto:rats@ietf.org>
List-Subscribe: <mailto:rats-join@ietf.org>
List-Unsubscribe: <mailto:rats-leave@ietf.org>


> On 2024-06-03, at 09:46, Thomas Fossati <thomas.fossati@linaro.org> wrote:
> 
> Hi Carsten,
> 
> On Fri, 31 May 2024 at 22:45, Carsten Bormann <cabo@tzi.org> wrote:
>>> I don’t understand.  This CDDL in Appendix A is normative, and so is the flexibility in its design to support JSON.  Otherwise, it would be “C< ...>” and not “JC<...>”.  I don’t take exception with providing a JSON binding but please explain this in the prose and in the introduction..
>> 
>> We now made it explicit that this is there as “CDDL you can use” — a normative intent when actually using this is desirable but the CDDL itself is not changing the specifications in any way, hence it is an informative appendix.  Line 462..465.
> 
> Hence, UJCS is *not* defined by draft-ietf-rats-uccs.  Correct?

Well, it is *defined*.
It is another name for the JWT claims set as defined in RFC 7519.
The UCCS document simply supplies CDDL that can be used for this.
The UCCS document also describes the role an unprotected claims set can have in the RATS context, specifically for UCCS.
There is no normative intent with this definition beyond that, but the description of the role of UCCS can be analogously applied to UJCS.
The normative intent of referencing UJCS would be in the document that uses this CDDL definition normatively.
Interestingly, Section 4.2.18 already reads exactly like this, without using the term UJCS (it only gives UCCS as an example).

> If so, we need to remove it from draft-ietf-rats-eat-media-type.

I don’t think that this is necessarily following.

> As an aside, I am starting to wonder whether it'd be better for
> draft-ietf-rats-eat-media-type to just drop the registrations for UCCS
> and let draft-ietf-rats-uccs handle it.

I think this could also very well be done (media type and content format, that is).
Is there a need to have “eat” in the name?
(I would probably also let the names reveal that UJCS and UCCS are not exactly the same data structures, so this would be application/uccs+cbor and application/ujcs+json.)

> Transplanting Section 6.7 [1] and moving the "ucs" line from Table 2
> [2] should do the trick, and disentangle the fate of the two
> documents.
> 
> cheers, t
> 
> [1] https://www.ietf.org/archive/id/draft-ietf-rats-eat-media-type-07.html#section-6.7
> [2] https://www.ietf.org/archive/id/draft-ietf-rats-eat-media-type-07.html#table-2