Re: [jose] [COSE] [EXT] Re: Multiple Suffixes with JOSE and COSE media types

[Brendan Moran <[e-mail]>]

As mentioned in the meeting:

If an object with a "typ" element gains a countersignature,
semantically speaking, the aggregate type is now changed. Is the typ
element now wrong?

This is complex, because it means that a countersignature effectively
makes the type incorrect.

To resolve this, you are required to either: verify countersignatures
first or disregard everything in the unprotected headers when
interpreting the typ header parameter.

Both of these introduce the same semantic paradox: If the
counter-signature(s) are excluded from the type, then the typ element
doesn't actually tell me what the aggregate type is. In a naive
interpretation, I don't know how to interpret the countersignatures
because the typ doesn't include them.

Obviously, I don't think we'll be looking at naive interpretations,
but I find it disconcerting that the element being introduced to
represent aggregate types will be incapable of representing aggregate
types that include countersignatures. Clearly, this is not solvable in
the way that it is presented. There are a few ways we could approach
it. Counter-signatures could add their own extensions to the header,
for example. This still has the disadvantage that the "real" type is
nested down in a header of a header.

 Arguably, the "typ" can never be trusted to represent the full
content of a COSE object because the unprotected header can change
without representation, leaving the designated type always
semantically incomplete.

I think, at the least, this needs some explanatory text in the draft.

Best Regards,
Brendan


On Fri, Jul 21, 2023 at 12:42 AM Orie Steele <[e-mail]> wrote:
>
> Inline:
>
> On Thu, Jul 20, 2023, 5:51 PM Michael Richardson <[e-mail]> wrote:
>>
>>
>> Orie Steele <[e-mail]> wrote:
>>     > `+jwt` secures `application/json` (already a registered structured
>>     > suffix)
>>
>> Yesish... but:
>>
>>     > `+cwt` secures `application/cbor` ( registration requests exist...
>>     > https://www.ietf.org/archive/id/draft-ietf-rats-eat-media-type-02.html#section-6.1
>>     > )
>>
>>     > `+cose` secures an envelope that is `application/cbor` and a payload of
>>     > type `content_type` (
>>     > https://github.com/anima-wg/constrained-voucher/issues/264 )
>>
>> Here I had a bit of pause.
>> Eventually I understood/remembered that +cwt isn't secure application/cbor.
>> Rather, it's securing application/cbor with a payload consisting of claims
>> from the CWT registry.  So while the underlying serialization is CBOR, it's
>> not securing arbitrary CBOR.
>>
>> (And that's why constrained-voucher does not use +cwt, because our claims
>> come from YANG, not from COSE)
>>
>>
>> A similar statement applies to +jwt, I think.
>
>
> There was discussion related to this recently on the COSE list, related to the cwt claims in header draft, and the typ COSE header parameters draft.
>
> Summarizing, payload is JSON for jwt, payload is CBOR for cwt.
>
> Afaik, all members are optional, but when present certain members have specific meaning.
>
> Using +jwt, and +cwt signals you want that meaning.
>
> This is relevant to W3C Verifiable Credentials, which... Which uses those meanings.
>
>>
>>     > `+jose` secures an envelope that is `application/json` and a payload of
>>     > type `cty` (AFAIK, nobody is planning to register this as of right
>>     > now).
>>
>> https://datatracker.ietf.org/doc/draft-ietf-anima-jws-voucher/  maybe.
>
>
> Thanks for pointing this out.
>
>>
>>     > You might consider these last 2 special cases of multipart content
>>     > types...  when their headers include `content_type` or `cty`.
>>
>> I kinda get why you are saying multipart, but I don't really like it that way.
>>
>>
>> I want to suggest that there are very few cases of real processing chains in
>> my opinion.  Except for debuggers.
>> +gz -type suffixes are the small exception to this.
>
>
> I agree with this.
>
> With the exception of polyglot formats in general... Which invite leveraging processing chains... This was the original reason for the multiple suffixes draft... +ld+json was rejected because there was no defined behavior for processing multiple suffixes...
>
> It's probably too late now, but this could easily have been solved by just doing +json-ld instead.
>
> A lot of people who have worked with +ld+json would probably agree that while it is json, you spend most of your time looking at the RDF it produces, and cursing about how hard it is to make both the json and the rdf look nice as the same time.
>
>
>>
>> --
>> ]               Never tell me the odds!                 | ipv6 mesh networks [
>> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
>> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [
>>
>>
>>
>> --
>> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>>            Sandelman Software Works Inc, Ottawa and Worldwide
>>
>>
>>
>>
>> _______________________________________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose
>
> _______________________________________________
> COSE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cose