Re: [Anima] [media-types] Thoughts on suffixes, single and multiple
> 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 into > 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. I fully agree with this! A generic +jws or +cose or +cbor or +json viewer with syntax and component highlighting would be super useful -- just like we have generic .txt / .json / .c file viewers today. For +cose for example, the viewer can immediately extract the signed payload part without necessarily knowing how to validate the signature, or knowing what key it needs for that. > Or maybe I should reverse this: in order for common tools to evolve, we need > clear signals about the encoding of the signature blob. Agree even more here :-) For the cBRSKI draft I looked at multiple suffixes, but saw it as getting too complex for us / the target population to understand and correctly apply. Without much benefit. A single +name prefix is useful however. > I think that application/voucher-cms+json in RFC8366 was in the wrong. > It should have been application/voucher-json+cms Yes, I also saw this a while back - the +cms at the end would have been the right thing. A generic +cms viewer could for example extract, or highlight the payload and also separately show the signing certificates even without necessarily being able to validate the CMS. The CMS structure itself can also contain a number indicating the payload type, in eContentType. The viewer can optionally use this to render the payload better. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [media-types] Thoughts on suffixes, single and multiple
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 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.
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 into
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 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.
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+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.
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.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [media-types] Thoughts on suffixes, single and multiple
Hi Michael,
> 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 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.
> 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)
>
> 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/
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
