Re: [Anima] [COSE] [Rats] cose+cbor vs cwt in MIME types

[Esko Dijk <[e-mail]>]

The security & safety aspect is definitely important here – I was assuming that a receiver that cannot understand/parse the full media type may just render some informative details about the data object to the user, or log these details in a nice way (so that a user reading the logs can understand), without necessarily continuing to process:
the receiver should not take any risky / critical actions like authorizing something, based on a partially parsed data item. Whatever the media type composition it remains the responsibility of the receiver to not be vulnerable to attacks done by an attacker e.g. sending half-correct data items to that receiver.

For example, if a receiver logs every failed request carrying a ‘eat+cwt+cbor’ item where the CWT is incorrect in a CBOR diagnostic notation in the log file; then the attacker has a nice way to try to overflow the logs. But the same problem is there if it would be an ‘eat+cwt’ media type, although slightly different perhaps. (The version of ‘eat+cwt+cbor’ may give a slightly larger attack surface in implementations. E.g. a developer may be more tempted to let the receiver treat the data item as CBOR as a fallback option and do something with it, thus wasting system resources.)

In ANIMA WG we just had a call to discuss we could have a ‘+cose’ subtype registered, so that our Voucher format could be “voucher+cose” or “voucher-cbor+cose” or so.   (The latter ‘-cbor’ is appended to distinguish from the archetypical Voucher data format which is JSON. The fact that the COSE wrapper is itself CBOR, is independent from that.)
Input from COSE WG members would be useful for this!

Esko


From: Orie Steele <[e-mail]>
Sent: Tuesday, April 4, 2023 17:27
To: Esko Dijk <[e-mail]>
Cc: Smith, Ned <[e-mail]>; Laurence Lundblade <[e-mail]>; Michael Richardson <[e-mail]>; Thomas Fossati <[e-mail]>; Thomas Fossati <[e-mail]>; cose <[e-mail]>; rats <[e-mail]>; [e-mail]
Subject: Re: [COSE] [Rats] [Anima] cose+cbor vs cwt in MIME types

Inline

On Tue, Apr 4, 2023 at 2:55 AM Esko Dijk <[e-mail]<mailto:[e-mail]>> wrote:
> So you can read the subtype "eat" and then consider it as +cwt, +cose, +cbor, for an example media type of "application/eat+cbor+cose+cwt"

It looks like in your example the order is reversed; given the existing examples defined in draft-ietf-mediaman-suffixes-03 Section 2.1?

Let’s assume it is the reverse, namely “application/eat+cwt+cose+cbor”. Then following the Section 2.1 examples a parser would go through these steps for example:


  *   Do I know “application/eat+cwt+cose+cbor” ? No.
  *   Do I know “+cbor” ? Yes, decode it as CBOR – ok it’s valid, proceed to next stage of the processing pipeline.
  *   Do I know “+cose” ? No. Processing stops here.

Is it safe to end here?


  *
  *   End result: I’ll render it in CBOR diagnostic notation.

Is this safe for a token format?


  *

Another parser might do these steps:


  *   Do I know “application/eat+cwt+cose+cbor” ? No.
  *   Do I know “+cbor” ? Yes, decode it as CBOR – it’s valid, proceed to next stage of the processing pipeline.
  *   Do I know “+cose” ? Yes, that’s COSE semantics – decode it – it’s valid, and although I can’t verify the signature, go to next stage of the processing pipeline.
  *   Do I know “+cwt” ? No, stop here.

Again is this safe place to end?


  *
  *   End result: display it as a COSE object. Do not trust it as I can’t verify the signature.

Exactly... This could be desirable, but it makes me a bit nervous... see "alg=none".


  *

Yet another parser:


  *   Do I know “application/eat+cwt+cose+cbor” ? No.
  *   Do I know “+cbor” ? Yes, decode it as CBOR – it’s valid, proceed to next stage of the processing pipeline.
  *   Do I know “+cose” ? Yes, that’s COSE – decode it – it’s valid, go to next stage of the processing pipeline.
  *   Do I know “+cwt” ? Yes, that’s a CWT – now checking that the COSE payload is correct CBOR with CWT structure inside – okay.
  *   End result: display it as a CWT.


For security oriented APIs this feels like where you want to end... Perhaps what we are seeing here is an interaction between "safe api design" and "trying to process stuff that might not be verified, or has been tampered with"...


Using the reverse way "application/eat+cbor+cose+cwt" seems not compatible with what’s currently written in draft-ietf-mediaman-suffixes-03 about “pipelines”.
For example, suppose a “CWT decoder” gets this media type first, and it then sends “eat+cbor+cose” to the next pipeline stage, that wouldn’t make sense since the ‘+cbor’ and ‘+cose’ parts were already decoded as part of ‘+cwt’.


I agree, but the JWT BCP uses at+jwt... so you either handle JWT or you fail... that seems desirable in most security cases.

For completeness here the example from the draft "image/svg+xml+gzip":

  *   Do I know "image/svg+xml+gzip" ? No.
  *   Do I know “+gzip” ? Yes, I can unzip the data – that works. Send the data to the next pipeline stage.
  *   Do I know “+xml” ? Yes, that’s just XML – can display it.

It is not "just XML".. it is "+xml" vs "application/xml"... this is discussed in the IETF 116 meeting (and there is no consensus on how the current draft should be interpreted).

- https://www.iana.org/assignments/media-types/application/xml

vs

- https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml
- https://www.rfc-editor.org/rfc/rfc7303.html#page-12


  *
  *   Do I know “svg” ? No.
  *   End result: display the object in my XML viewer.

(Using here "image/svg+gzip+xml" would lead to incorrect results clearly.)

Yes, this makes me wonder what happens to protected and unprotected headers, when processing anything with +cwt or +cose in the middle of multiple suffixes... to me this suggests that they cannot go "in the middle', unless everything to the left expects them.

I suppose this concern also applies to +jwt, except in those cases the intention is very clearly to produce a specific subtype that is also a JWT.

Arguing against myself:

“application/eat+cwt+cose+cbor”  seems ok if the goal is to end at COSE without verifying (a tamper friendly media type).

“application/eat+cwt” seems ok if the goal is to end at an eat token or fail (tamper unfriendly)

I am nervous about specifying "verifiable media types" that in practice processing of verifying can be skipped, and it seems like multiple suffixes is a gateway to seeing more of these in the future.

I think it would be nice if the suffixes draft commented on cases where digital signatures might interact with suffixes, including commenting on +jwt and +cose.


Esko

From: Orie Steele <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, April 4, 2023 02:09
To: Smith, Ned <[e-mail]<mailto:[e-mail]>>
Cc: Laurence Lundblade <[e-mail]<mailto:[e-mail]>>; Esko Dijk <[e-mail]<mailto:[e-mail]>>; Michael Richardson <[e-mail]<mailto:[e-mail]>>; Thomas Fossati <[e-mail]<mailto:[e-mail]>>; Thomas Fossati <[e-mail]<mailto:[e-mail]>>; cose <[e-mail]<mailto:[e-mail]>>; rats <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [COSE] [Rats] [Anima] cose+cbor vs cwt in MIME types

Per the JWT BCP, regarding typ.

https://datatracker.ietf.org/doc/html/rfc8725#name-use-explicit-typing

The +jwt suffix goes on the end.

You would need to register +eat as a structured suffix otherwise.

My understanding is that you currently intend to register application/eat as a subtype, not a structured suffix (you can do both, see json).

The 116 meeting mentions that while it is the case today that most structured suffix are also registered subtypes, this might not be a reliable assumption in the future.

The current multiple suffixes draft makes it clear that processing of suffixes is right to left (confusing / surprising perhaps).

So you can read the subtype "eat" and then consider it as +cwt, +cose, +cbor, for an example media type of "application/eat+cbor+cose+cwt"

As I mentioned before, the multiple suffixes draft might not land... So it would be better to avoid multiple plus and follow the conventions from the JWT BCP, and avoid registering new or interesting suffixes, given the current confusion regarding them.

I'm not saying any of this is correct, just noting what the suffixes draft says today, and how it is related to the several +jwt media types that have already been registered.

Another interesting case to consider... Data URI of type "eat+jwt+gzip"... Since base64 URL encoding can quickly max out QR Codes / NFC or URL limits.

Decompress, verify, parse / validate.

OS


On Mon, Apr 3, 2023, 6:36 PM Smith, Ned <[e-mail]<mailto:[e-mail]>> wrote:
> application/eat+cbor+cose+cwt

EAT is a specialization of a CWT or a JWT. What in eat is encoded before the cbor (which encodes the token)?

If the conceptual message is identified by a message wrapper draft-ftbs-rats-msg-wrap-02 - RATS Conceptual Messages Wrapper (ietf.org)<https://datatracker.ietf.org/doc/draft-ftbs-rats-msg-wrap/>, then the cbor bytes could be encoded in an cmw array. As in:
`[ “application/cbor+cose+cwt+eat”, bstr ]`

The discussion around cmw hasn’t concluded, but in theory, the array structure could be embedded in a conveyance protocol or message that would have some way to identify it as a cmw. The cmw I-D doesn’t try to define a media type name for `cmw-array`. Hopefully, that isn’t needed. But it is the outer most onion skin before talking about conveyance protocol / message framing.

-Ned

From: Orie Steele <[e-mail]<mailto:[e-mail]>>
Date: Monday, April 3, 2023 at 3:21 PM
To: "Smith, Ned" <[e-mail]<mailto:[e-mail]>>
Cc: Laurence Lundblade <[e-mail]<mailto:[e-mail]>>, Esko Dijk <[e-mail]<mailto:[e-mail]>>, Michael Richardson <[e-mail]<mailto:[e-mail]>>, Thomas Fossati <[e-mail]<mailto:[e-mail]>>, Thomas Fossati <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [COSE] [Rats] [Anima] cose+cbor vs cwt in MIME types

Inline:

On Mon, Apr 3, 2023 at 3:10 PM Smith, Ned <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Date: Monday, April 3, 2023 at 12:44 PM
To: Orie Steele <[e-mail]<mailto:[e-mail]>>
Cc: "Smith, Ned" <[e-mail]<mailto:[e-mail]>>, Esko Dijk <[e-mail]<mailto:[e-mail]>>, Michael Richardson <[e-mail]<mailto:[e-mail]>>, Thomas Fossati <[e-mail]<mailto:[e-mail]>>, Thomas Fossati <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Date: Monday, April 3, 2023 at 10:47 AM
To: "Smith, Ned" <[e-mail]<mailto:[e-mail]>>
Cc: Esko Dijk <[e-mail]<mailto:[e-mail]>>, Michael Richardson <[e-mail]<mailto:[e-mail]>>, Thomas Fossati <[e-mail]<mailto:[e-mail]>>, Thomas Fossati <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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://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 <[e-mail]<mailto:[e-mail]>> 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" <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> on behalf [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>> 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 <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>> On Behalf Of Michael Richardson
Sent: Monday, March 27, 2023 01:19
To: Thomas Fossati <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>; Thomas Fossati <[e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>>; [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>
Subject: Re: [Anima] [Rats] cose+cbor vs cwt in MIME types


Michael Richardson <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>> 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
[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
https://www.ietf.org/mailman/listinfo/anima <https://www.ietf.org/mailman/listinfo/anima>


_______________________________________________
RATS mailing list
[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>



_______________________________________________
COSE mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/cose


--
ORIE STEELE
Chief Technical Officer
www.transmute.industries<http://www.transmute.industries>

Error! Filename not specified.<https://www.transmute.industries/>


--
ORIE STEELE
Chief Technical Officer
www.transmute.industries<http://www.transmute.industries/>

Error! Filename not specified.<https://www.transmute.industries/>
_______________________________________________
COSE mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/cose



--
ORIE STEELE
Chief Technical Officer
www.transmute.industries<http://www.transmute.industries>



--
ORIE STEELE
Chief Technical Officer
www.transmute.industries<http://www.transmute.industries>

[https://drive.google.com/a/transmute.industries/uc?id=1hbftCJoB5KdeV_kzj4eeyS28V3zS9d9c&export=download]<https://www.transmute.industries/>