Inline: On Mon, Apr 3, 2023 at 3:10 PM Smith, Ned <[email protected]> wrote:
> > there’s no standard for the key material and key identification > > The observation is that the COSE block contains a key-id that can be used > to locate the key material (e.g., I assume key material refers to the > public key needed to verify the COSE signature given asymmetric crypto). > The COSE parser (layer) would normally be equipped to handle this sort of > thing. If the media type was ‘cwt’ the parser would have to support > everything in the COSE layer as well as what’s in the token part as well. > EAT adds additional parsing requirements on top of CWT. Hence, the > expression “application/cbor+cose+cwt+eat” isn’t unreasonable. > I would expect something more like this (according the current suffixes draft): application/eat+cbor+cose+cwt or simply: application/eat+cwt (since cwt implies cbor + cose) Closest JWT analogy currently in the registry: - https://www.iana.org/assignments/media-types/application/at+jwt - https://www.rfc-editor.org/rfc/rfc9068.html keep in mind the multiple suffixes is not yet an RFC... if you can avoid multiple suffixes, I think it is very wise to do so. The reason to use multiple suffixes is to signal that there is meaningful processing that can be done... for token formats, I feel this is less true than json flavors, such as "application/vc+ld+json". I had a discussion with friends at IETF 116 about "sd+jwt" vs "sd-jwt", related to https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-03.html#name-iana-considerations-24 For example, sd-jwt implies normal jwt processing is not meaningful, whereas sd+jwt implies jwt processing is meaningful... There were good arguments on both sides. Given the current state of consensus on multiple suffixes, I would potentially avoid taking a dependency on it if possible, sticking to just 1 plus. > > Someone could argue that “…+cose+cwt…” doesn’t add anything, as “+cwt” > alone could infer both. The same is true for “…cbor+eat…”. > > But I think there is value in being able to describe a fully qualified > representation that is the primitive representation after the various > inferred representations have been computed. > > > > > but that’s about the library, not dispatching some content arriving to a > particular application > > I think the value is it doesn’t assume monolithic applications. A library > or processor that is specific to the encoding between the pluses, e.g., > “+cose+”, can be used in some sort of highly optimized pipeline, rather > than presumed to be a monolith. > > > > *From: *Laurence Lundblade <[email protected]> > *Date: *Monday, April 3, 2023 at 12:44 PM > *To: *Orie Steele <[email protected]> > *Cc: *"Smith, Ned" <[email protected]>, Esko Dijk < > [email protected]>, Michael Richardson <[email protected]>, > Thomas Fossati <[email protected]>, Thomas Fossati < > [email protected]>, "[email protected]" <[email protected]>, "[email protected]" < > [email protected]>, "[email protected]" <[email protected]> > *Subject: *Re: [COSE] [Rats] [Anima] cose+cbor vs cwt in MIME types > > > > I’m not sure identifying something as COSE, or even CWT is that useful > because there’s no standard for the key material and key identification > that cuts across all uses of COSE or CWT. > > > > For example with EAT the receiver probably will need an endorsement (a > very specific thing with very specific semantics) with a public key to be > able to process the CWT/COSE. If COSE is used for encrypted email (a future > S/MIME), the key material identification will probably be really different. > It’s hard for me to see what a generic COSE/CWT handler is going to do > here. It’s good and well if an EAT processor uses the same COSE library as > an S/MIME processor, but that’s about the library, not dispatching some > content arriving to a particular application. > > > > No objection to the work here. Just some observations. > > > > LL > > > > > > > > On Apr 3, 2023, at 11:14 AM, Orie Steele <[email protected]> > wrote: > > > > Yes! That seems to have been one proposal, related to cleaning up the > registry and clarifying interpretation. > > If you have strong opinions on this, please help contribute to the dialog > on this media types list: > > > https://mailarchive.ietf.org/arch/msg/media-types/qO72m31whV5QZmV6kj55KDqS8n8/ > > Regards, > > OS > > > > On Mon, Apr 3, 2023 at 1:12 PM Smith, Ned <[email protected]> wrote: > > Interesting! > > It would be nice if I-D.ietf-mediaman-suffixes could define a backward > compatibility convention that shows how existing / registered > media-type-names can co-exist with I-D.ietf-mediaman-suffixes. > > > > > > *From: *Orie Steele <[email protected]> > *Date: *Monday, April 3, 2023 at 10:47 AM > *To: *"Smith, Ned" <[email protected]> > *Cc: *Esko Dijk <[email protected]>, Michael Richardson < > [email protected]>, Thomas Fossati <[email protected]>, Thomas > Fossati <[email protected]>, "[email protected]" <[email protected]>, " > [email protected]" <[email protected]>, "[email protected]" <[email protected]> > *Subject: *Re: [COSE] [Rats] [Anima] cose+cbor vs cwt in MIME types > > > > At IETF 116 this draft was discussed: > > - https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes > - https://youtu.be/BrP1upACJ0c?t=1744 > > TLDR; there is work in progress to define multiple suffixes, and how they > are interpreted. > > This would be relevant to potential future +cwt media types, it is already > causing us some concern with respect to special cases of +jwt. > > Regards, > > OS > > > > On Mon, Apr 3, 2023 at 12:28 PM Smith, Ned <[email protected]> wrote: > > It seems the early registrations focused on encoding formats for content > to the right of the "+" like '+xml', '+json', '+cbor', '+der', while later > registrations seem to include schema formats like '+jwt', '+sqlite3', and > '+tlv'. > > It would have been nice if the registry defined the right side for > encoding formats and let the left side contain content / schema formats > IMHO. That way, the parsers could scan for the "+" to identify if it > supports the encoding format as a first pass operation. If it can't decode > the first byte, then there's no point in going further. > > If it can decode, then the first byte/bytes may provide insight into what > content is there. For example, a CBOR tagged structure. But additionally, > the left hand side identifies schemas. Given many data structures can be > integrity protected, signed, and encrypted. Supplying a value that > describes a cryptographic enveloping schema / format seems like a > reasonable requirement for the '-label' to the immediate left of the plus, > e.g., "-cose+cbor". > The data within the cryptographic envelope may follow a well-defined > schema such as the RATS ar4si. E.g., "ar4si-cose+cbor". I don't see a > problem with omitting the cryptographic envelope label if no envelope is > provided. E.g., "ar4si-+cbor". > > JWT and CWT are both an envelope and a data model schema, so the > cryptographic envelope could be inferred. But it wouldn't be incorrect to > restate the obvious for the benefit of the parsers who only care about > cryptographic wrapper processing. E.g., "jwt-jose+json" is still a > reasonable way to encode 'jwt'. > > If there are content schemas that are to the left of some other content > schema, then that can be accommodate easily by prepending another 'label-'. > E.g., "ar4si-jwt-jose+json". > > This approach allows an initial parser / message router to get a view of > all the parsers needed to fully inspect the message in advance of making an > initial message routing decision which would enable efficient parser > offload architectures. There could be different registries for the > different types of structure "+label" for encoding formats only, "-label" > to the immediate left of "+" for cryptographic enveloping, and application > formats for the next left most content. > > To make processing even more efficient, the content-type-name should > reverse the order based on outer-most format. E.g., "json+jose-jwt-ar4si". > This way buffer only needs to contain the first bytes up to the '+' and so > forth. > > I realize this goes beyond the initial focus of the discussion thread. But > IETF is also concerned about the long-term future of the Internet and in > optimizing wherever it makes sense. Content typing is just a form of deep > packet inspection that goes beyond network framing. > > Cheers, > Ned > > On 4/3/23, 12:33 AM, "RATS on behalf of Esko Dijk" <[email protected] > <mailto:[email protected]> on behalf [email protected] > <mailto:[email protected]>> wrote: > > > Hi, > > > As for the questions mentioned on these slides: > > > 1. "Is is '-cose+cbor' or '-cbor+cose' > > > The registry > https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml > < > https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml> > lists the subtypes that one have after the '+' sign. > 'cbor' is there but 'cose' is not. 'cwt' is also not there. > > > So for the moment, registering a 'mytype+cose' or 'voucher+cose' or > 'voucher-cbor+cose' is not possible now unless you would also register the > '+cose' as a subtype. RFC 9052 did not choose to register the subtype > '+cose', for whatever reason. > > > Luckily because COSE is just "plain CBOR" itself , we can use the subtype > '+cbor'. So having "voucher-cose+cbor" would be fine. Also "voucher+cbor" > would be equally ok albeit a little bit less informative that it contains > COSE. > > > > > 2. "are they sufficiently different" (this is about > application/voucher-cose+cbor and application/eat+cwt formats) > > > The voucher is not a CWT format, e.g. it does not use the standardized CWT > claims at all. It defines an own format within the constraints of YANG > CBOR, while CWT does not use any YANG semantics. > > > (Now converting the constrained Voucher format into a CWT based format > would certainly be possible; but that's probably not the discussion > intended by these slides.) > > > Regards > Esko > > > PS more detailed info at > https://github.com/anima-wg/constrained-voucher/issues/264 < > https://github.com/anima-wg/constrained-voucher/issues/264> > https://github.com/anima-wg/constrained-voucher/issues/263 < > https://github.com/anima-wg/constrained-voucher/issues/263> > > > -----Original Message----- > From: Anima <[email protected] <mailto:[email protected]>> On > Behalf Of Michael Richardson > Sent: Monday, March 27, 2023 01:19 > To: Thomas Fossati <[email protected] <mailto:[email protected]>>; > Thomas Fossati <[email protected]<mailto:[email protected]>>; > [email protected] <mailto:[email protected]>; [email protected] <mailto:[email protected] > >; [email protected]<mailto:[email protected]> > Subject: Re: [Anima] [Rats] cose+cbor vs cwt in MIME types > > > Michael Richardson <[email protected] <mailto:[email protected]>> > wrote: > > COSE CHAIRS: can we have 5 minutes for this discussion? > > I guess I can make two slides tomorrow and get Thomas to co-author them. > > > I guess we didn't get any time at COSE. > > > > https://github.com/anima-wg/voucher/blob/main/presentations/ietf116-cose-mime-cwt.pdf > < > https://github.com/anima-wg/voucher/blob/main/presentations/ietf116-cose-mime-cwt.pdf > > > > > _______________________________________________ > Anima mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/anima < > https://www.ietf.org/mailman/listinfo/anima> > > > _______________________________________________ > RATS mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/rats < > https://www.ietf.org/mailman/listinfo/rats> > > > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > > > > > -- > > *ORIE STEELE* > > Chief Technical Officer > > www.transmute.industries > > > > *Error! Filename not specified.* <https://www.transmute.industries/> > > > > > -- > > *ORIE STEELE* > > Chief Technical Officer > > www.transmute.industries > > > > [image: Image removed by sender.] <https://www.transmute.industries/> > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > > > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
