Mark Nottingham <[email protected]> wrote: >> On 5 Apr 2024, at 07:21, Michael Richardson <[email protected]> >> 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 <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
