From mcr+ietf@sandelman.ca Fri Apr 5 04:37:52 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 76C33C151071; Fri, 5 Apr 2024 04:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.097 X-Spam-Level: X-Spam-Status: No, score=-7.097 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_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=sandelman.ca 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 leDaUZGQHIXS; Fri, 5 Apr 2024 04:37:47 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (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 5D85BC151070; Fri, 5 Apr 2024 04:37:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 4F7D13898B; Fri, 5 Apr 2024 07:37:46 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OXA3_WHMrHHR; Fri, 5 Apr 2024 07:37:45 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 05BFF38988; Fri, 5 Apr 2024 07:37:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1712317065; bh=YF10M8dJLCU9CacSLOB5XowuuHaZZ5azIy+9dzMMtV0=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=FN4Tzq8uCO+yn1WtpRwochdTsPxuhHsQhfSbcysA2GDnpY1KQmb7OyYTbJO8XcBza TL7z2nmxe/RvDkMEoxblI/jOv3RB37PH6jmXDjhfgxw5NhYPnG838Svk1AEvS+9MNw wz7sYWtfBf+3/dj6xJzNNzb7O9s7d2iqKro0+JSWBLtxPrGqq0wKboRlBbfmZ5hrz2 1Nn2sTAEPlWsWYWxvJdVS4s6zXJXR2HyH15GnrbD2vOaDkwm9YhC/tVb+j0CJ8TUeG GYWOLsX2xD2Et/R848otZU0xG5yi68NtJA6YfUWamBRkERPmhwpoRg1oGmN82Fj7Z0 kg2TwjbU3SHEA== Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0148750; Fri, 5 Apr 2024 07:37:45 -0400 (EDT) From: Michael Richardson To: Mark Nottingham cc: media-types@ietf.org, anima@ietf.org In-Reply-To: References: <2E20FEDE-C766-43EE-A6E2-1FB63E79CF0B@mnot.net> <1810.1712262101@obiwan.sandelman.ca> X-Mailer: MH-E 8.6+git; nmh 1.8+dev; GNU Emacs 28.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m 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 11:37:52 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mark Nottingham wrote: >> On 5 Apr 2024, at 07:21, Michael Richardson >> wrote: >> >> 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). >> >> 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? >> >> (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 med= ia > 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. I don't think that it matters to surface the signature format at all for normal usage of vouchers in BRSKI. The media types are just blobs. (And on CoAP, they are Content-Formats, which are a single integer) The utility to the community is that if a dissector (debug tool) can see it= 's a signature, then it can, even without verifying the signature, dig down in= to the payload to show a developer what's what. It seems reasonable to common tools will evolve to decode JWS and COSE, but not necessarily know what a voucher is. Or maybe I should reverse this: in order for common tools to evolve, we need clear signals about the encoding of the signature blob. > 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 t= he > 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. Yes, that does summarize things. I think that application/voucher-cms+json in RFC8366 was in the wrong. It should have been application/voucher-json+cms (and then application/voucher-json+jws ) >> 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+gzi= p, > can I assume that application/foo+xml is also registered, and that > decompressing will result in something that conforms to it? If so, th= at > gets us back into the processing model mess that's bedevilled the WG > for a long time. Yes, I think that foo+xml should also have be registered. It might be that application/foo is nonsense though. >> 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) >> >> 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? To my format capable decoder/pretty-printer. For JSON and XML, which are fundamentally text, thinking of that as my editor is reasonable. For CMS (= ASN.1), COSE, CBOR and other binary encodings, then it's not text, but there might = be a text-like content within. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQFKBAEBCgA0FiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmYP4ogWHG1jcitpZXRm QHNhbmRlbG1hbi5jYQAKCRCAi3D73dDdZWCAB/48IelCRD4liGi7MWcsM2ykNDR/ TrMDzM1ujy6whrYcyZK6zEQjAmFRQH1gaqQAeDMZ4Ase7XXwoNn7OEXBcF5RMXza b0MX3d3yhIeFkfO5mE0IKFzs7NPZ8eoEzLyq1yUTty8CBZgLpbKAjcFb72KaVVly iNHTP/SDnJgaT2aE+zAQt7nav94c+lDGNeMJ4JZQaFLcSqHcVtGj88lSggeqwmQf w9V94BGBtTfkxcp9QZGH/gaI9+xTkNByjRF277xWFvKCavrfcZYK0r6O+Tqul9AH aiMMjtXodsWOd8G5hUJ3BAUcrNI800gFSzv3/KKiBjUs39Ih4Ksq9zJHqAFb =ssQV -----END PGP SIGNATURE----- --=-=-=--