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

[Orie Steele <[e-mail]>]

+1 to the commentary on keeping payloads opaque until after security checks.

One interesting difference between jose and cose, is that jose has:

typ: the content type of the token.
cty: the content type of the payload.

For most JWT use cases the cty value is sorta redundant, since we expect
the payload to be of type application/json.

For COSE, there is no registered tag for typ, and we might expect many
different cty values, since COSE is friendlier as an envelope format to
wrapping different content types.

I am not sure about CWTs, are they also expected to produce cbor or can
they be used to produce json after verify?

I am intrigued by the difference between:

jwt+json (doesn't make sense)
json+jwt (alternative name for JWT?)

And

cwt+cbor (kinda makes sense)
cbor+cwt (alternative name for CWT?)

According to the JWT BCP, the specific typing is used to distinguish
different types of tokens, and so:

typ: subtype+jwt

Just to highlight the draft / todos related to this thread:

1. Multiple suffixes draft
2. +cwt suffix registration
3. typ tag for COSE (if parity with JWT BCP is desired)

OS


On Tue, Apr 4, 2023, 3:35 PM Smith, Ned <[e-mail]> wrote:

> +1 to:
>
> > 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.
>
>
>
> It seems the intent of having a security envelope is that what is inside
> the envelope remains off limits (opaque) until the security checks are
> satisfied.
>
> The content-type-name conventions could model the intent that envelope
> payloads remain opaque by excluding them from a content-type-name structure
> that includes a crypto envelope (e.g., cose, jose, cwt, jwt, eat). When the
> cryptographic processing is complete, what remains is the payload and that
> payload should/could have a different content-type-name. RATS found it
> helpful to define uccs to represent unsigned cwt. For example, if an ar4si
> structure was placed in a cose envelope, the content-type-name might be
> “application/cose+cbor”. Following the processing of the envelope, the
> resulting content might have a content-type-name of
> “application/ar4si+cbor”. Alternatively, if the envelope was
> “application/cwt+cbor”, the resulting verified output might be
> “application/ar4si+uccs”.
>
>
>
> Any of the token types (jwt, cwt, eat) are interesting because they have
> both an envelope and a content (that is intended to be opaque until after
> the security checks are finalized).
>
>
>
> In the case of cwt, uccs [I-D.ietf.rats.uccs] would be the expected
> emergent content type. But even if cose was used instead of cwt, uccs could
> still be a reasonable emergent content type.
>
>
>
> Keeping crypto enveloped payloads opaque also implies content-type
> nesting.
>
>
>
> *From: *RATS <[e-mail]> on behalf of Esko Dijk <
> [e-mail]>
> *Date: *Tuesday, April 4, 2023 at 9:16 AM
> *To: *Orie Steele <[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]" <
> [e-mail]>
> *Subject: *Re: [Rats] [COSE] [Anima] cose+cbor vs cwt in MIME types
>
>
>
> 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]>
> 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]>
> *Sent:* Tuesday, April 4, 2023 02:09
> *To:* Smith, Ned <[e-mail]>
> *Cc:* Laurence Lundblade <[e-mail]>; Esko Dijk <
> [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
>
>
>
> 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]> 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]>
> *Date: *Monday, April 3, 2023 at 3:21 PM
> *To: *"Smith, Ned" <[e-mail]>
> *Cc: *Laurence Lundblade <[e-mail]>, Esko Dijk <
> [e-mail]>, Michael Richardson <[e-mail]>,
> Thomas Fossati <[e-mail]>, Thomas Fossati <
> [e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[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]> 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]>
> *Date: *Monday, April 3, 2023 at 12:44 PM
> *To: *Orie Steele <[e-mail]>
> *Cc: *"Smith, Ned" <[e-mail]>, Esko Dijk <
> [e-mail]>, Michael Richardson <[e-mail]>,
> Thomas Fossati <[e-mail]>, Thomas Fossati <
> [e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[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]>
> 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]> 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]>
> *Date: *Monday, April 3, 2023 at 10:47 AM
> *To: *"Smith, Ned" <[e-mail]>
> *Cc: *Esko Dijk <[e-mail]>, Michael Richardson <
> [e-mail]>, Thomas Fossati <[e-mail]>, Thomas
> Fossati <[e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <[e-mail]>, "[e-mail]" <[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://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]> 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]> on behalf [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]>> On
> Behalf Of Michael Richardson
> Sent: Monday, March 27, 2023 01:19
> To: 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]>
> Subject: Re: [Anima] [Rats] cose+cbor vs cwt in MIME types
>
>
> Michael Richardson <[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]>
> https://www.ietf.org/mailman/listinfo/anima <
> https://www.ietf.org/mailman/listinfo/anima>
>
>
> _______________________________________________
> RATS mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rats <
> https://www.ietf.org/mailman/listinfo/rats>
>
>
>
> _______________________________________________
> COSE mailing list
> [e-mail]
> 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
>
>
>
> *Error! Filename not specified.* <https://www.transmute.industries/>
>
> _______________________________________________
> COSE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cose
>
>
>
>
>
>
> --
>
> *ORIE STEELE*
>
> Chief Technical Officer
>
> www.transmute.industries
>
>
>
>
>
>
> --
>
> *ORIE STEELE*
>
> Chief Technical Officer
>
> www.transmute.industries
>
>
>
> [image: Image removed by sender.] <https://www.transmute.industries/>
>