From mnot@mnot.net Fri Apr 5 00:09:00 2024 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D551FC14F6A6; Fri, 5 Apr 2024 00:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b="h8lmddeB"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="M/2AmQX6" 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 bz10ay_BO0N1; Fri, 5 Apr 2024 00:08:56 -0700 (PDT) Received: from fhigh6-smtp.messagingengine.com (fhigh6-smtp.messagingengine.com [103.168.172.157]) (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 04DA6C14F680; Fri, 5 Apr 2024 00:08:55 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfhigh.nyi.internal (Postfix) with ESMTP id AC3FA11400EF; Fri, 5 Apr 2024 03:08:54 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 05 Apr 2024 03:08:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1712300934; x=1712387334; bh=cLqSo1sJlttskUHPOW9iU+IRhRrO3imvnpE8lruzJRo=; b= h8lmddeBARxZxV2kV5WsE+em0m5Ylvl7UTc6WqT0ryr8mo8rdISOW31YNRHDKSjp f9ZL/tWAxeynoSamLWe6sJjizchzTEXwc25Ht9ovqq6lpGj+naW7I8Cn9fcw8zRg gp6dSdD0z0PZ+km//km19kHNi6EgDCqM0dEG5g71guE1bRLnjj2KlB4K5k+a5z8Y jGu7+7L3zZrarUFklt48kKaQPP0fzeFRpB5Fs7mxA481Vmz8ArxrWG5m25tP4x+Y SSrnNFDRoazRrhuO8h53Pk1KDth/MtSmbojD3KDihV1vOF1oGxkY6lnkFlRBNHex +EzG1TP7XYOCFb4aXknB/w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1712300934; x= 1712387334; bh=cLqSo1sJlttskUHPOW9iU+IRhRrO3imvnpE8lruzJRo=; b=M /2AmQX64iL8uopq75GcGvsuSR4YhYx1NU+dNd56LgFU6hskGHFdFj/QTcmkWznAd HnlmUZCvrQTirThXfRkmoYotHhTgDhxSiATWl7np3GXhHaakfoUCNR3mxKGIey/m fXRGt2efJcJb5qjCZE8SnfR9QaIdN/jMudDR5/U54URDaaxQAJO/qHNxl8TsPurc JnJ3QsuJwmWIbAbeGgs8ngnDyBesweXI8ar8cD/KDWJ4BXPFL8cCBmxrAmaNTciQ gX/fm1OtU+mf5wDuF2tGuT0tX/2aaWwHFTVtKTk0OgWGceNKfccwo/m/vf5YSiC7 umycwtu1tuTBQZ0dxu80g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudefledguddujecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffvefgkfhfvffose htqhhmtdhhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohht sehmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnheptddtgefgueevtddugfdtkeffud egveetffegjeelhfdvtedvueejteegueegteetnecuffhomhgrihhnpehmnhhothdrnhgv thenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnh hothesmhhnohhtrdhnvght X-ME-Proxy: Feedback-ID: ie6694242:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 5 Apr 2024 03:08:53 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) From: Mark Nottingham In-Reply-To: <1810.1712262101@obiwan.sandelman.ca> Date: Fri, 5 Apr 2024 15:08:51 +0800 Cc: media-types@ietf.org, anima@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <2E20FEDE-C766-43EE-A6E2-1FB63E79CF0B@mnot.net> <1810.1712262101@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3774.500.171.1.1) Archived-At: Subject: Re: [Anima] [media-types] Thoughts on suffixes, single and multiple X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2024 07:09:00 -0000 Hi Michael, > On 5 Apr 2024, at 07:21, Michael Richardson = wrote: >=20 > We in ANIMA have been struggling because we have an artifact, a = voucher > (YANG defined in RFC8366, being revised/extended in 8366bis), which = can be in > two major formats: JSON and CBOR (in theory, XML too), but can be = signed by > three formats (CMS, JWS, COSE). >=20 > That gives us three major variations today: > 1) application/voucher-cms+json aka voucher+json+cms? > 2) application/voucher+cose or? voucher+cbor+cose? > 3) application/voucher-jwt+json aka voucher+json+jwt? >=20 > (because CMS signing CBOR seems dumb, as does mixing {JSON,CBOR} X = {JWS,COSE}) It would be very helpful if you could give us insight into why it's = important to surface the signature format (CMS, JWS, COSE) in the media = type **in a manner that's apparent to consumers who don't understand the = semantics of the specific media type**. If it only needs to be apparent = to the application-specific software processing the voucher, you could = easily use application/voucher-cms+json -- and you may even be able to = use application/voucher+json if the format is capable of distinguishing = between signature formats internally. Your question also highlights the confusion and a problem around = suffixes. If you use application/voucher+json+cms, it means that generic = software that expects to see +json as the last component of the media = type suffix (for an example, a web browser that can display "pretty" = JSON, which at this point is theoretical, but it's the best example we = have for suffixes) will not recognise it. However, if you use = application/voucher+cms+json, generic software that expects +cms to be = the final suffix won't function correction.=20 > Also, +gzip makes it pretty clear you can maybe do something with it, = if you > just know how to decompress. But what does it imply? For example, if I see application/foo+xml+gzip, = can I assume that application/foo+xml is also registered, and that = decompressing will result in something that conforms to it? If so, that = gets us back into the processing model mess that's bedevilled the WG for = a long time. > So, +jwt and +cose says, "this is a signed object, and if you look in = the > payload slot, you might find something you might know how to decode" = (or not) >=20 > But, for many formats they only appear in a signed form in the wild, = so maybe > this just doesn't matter. To ask the questions above in a slightly different way: To whom are +jwt = and +cose speaking to here, other than the code handling the specific = media type? Cheers, -- Mark Nottingham https://www.mnot.net/