Subject: [COSE] [Cose]: RFC8152(bis) question(s) (draft-ietf-anima-constrained-voucher)

From: Toerless Eckert <[email-masked]>
Date: Thu, 22 Jul 2021 18:01:35 +0200

While following our anima hackathon for draft-ietf-anima-constrained-voucher,
i stumbled across not understanding some details. Maybe beside helping me
understanding in this thread, some of these questions might also be good
to be answered with better text in rfc8152bis.

My basic confusion is probably around the distinction between Syntax and Semantics.
rfc8152(bis) specifies a couple of Media Types and CBOR IDs to characterize 
the COSE blob and calls this the Semantic. But the only semantic that is
indicated by the items in Table 1/2 (cose-sign...cose-mac0) seems to be
the semantic of the cose-type, but not the semantic of the content.

Unfortunately, i don't know what outside of its use in our anima draft
example contant types would be. As far as i could find, none of the examples
in appendix C nor in https://github.com/cose-wg/Examples do have
the "content type" (3:) field with a value and none seem to elaborate
about different type of payloads.

In practice, we do need to indiate in the Media Type of a COSE blob
the semantic of the content and not only of the COSE "signing" semantics
This is why we are wanting to register a Media Type of
application/voucher-cose+cbor

Now if our approach of asking for sucha  media type to identify the cose content
semantic and not only the cose function semantic is the correct approach,
would i then not have o already find other media types for other ietf solutions
using cose ? I can not find any other Media Types in the IANA registry though..
Are there any ongoing that have not asked for early allocation yet ?

If my thinking is not correct, then it would be good to hear wha the
correct approach is to designate a media type to uses of cose.

Which brings me to the content type field. 

"Applications SHOULD provide this header parameter if the content structure is potentially ambiguous"

I would like to understand an example when the content structure is and 
when it is not ambiguous.

And of course, for the content type field, there is again the question
whether it should indicate only the syntax of the payload (CBOR) or
the semantic+syntax... And an answer of "COSE doesn't care, its up to
the user of COSE" is fine, but any such guidance would be helpfull
to have in rfc8152bis for adopters of COSE (such as us).

Thanks!
    Toerless

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 22 Jul 2021 18:20:18 +0200

On 22. Jul 2021, at 18:01, Toerless Eckert <[email-masked]> wrote:
> 
> As far as i could find, none of the examples

I won’t try to answer the whole question, but let’s just look at one example:
The European Digital Green Card (Covid pass) uses a CWT with claim -260.
Given that the claim -260 is registered in the CWT registry [1], there is no need to provide any other semantics with the signed object.
Similar with the FIDO entries there.

If you do not use a CWT, you may want some other form of identification of what the payload is about, and the COSE content-type header parameter (3) is one of them.

Grüße, Carsten

[1]: https://www.iana.org/assignments/cwt/cwt.xhtml
Scroll down to hcert

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 22 Jul 2021 18:41:05 +0200

> Given that the claim -260 is registered in the CWT registry [1], there is no need to provide any other semantics with the signed object.

?? Let me see if i correctly parsed the relevant info from the docs:

-> A CWT is a COSE object right ?

-> RFC8392 does specify a Media Type application/cwt for it, so there IS
   some level of semantic for the COSE payload expressed in the COSE object Media Type.
   Except that the actual semantic of the cwt is in the CBOR claim key field.

If i understand it right, this would be an example i was looking for,
and given the short name 'cwt' i couldn't find it, looking for 'cose' in the
Media Type registry. I guess our work could equally have asked for a
more hib abbreviation application/cbv (constrained brski voucher) ;-)

I am not so sure if demuxing the actual semantic by the claim key field
alone would be sufficient when you had cases where you may needed to find
a specific type CWT. Like when you had a drawer full of tokens, and you
wanted to find the health certificate purely from the envelope without
having to open up the COSE envelope and look into the claim key field of
every token in the drawer. But i guess the expectation in general is that
you wouldn't run into this situation in the targeted use-cases, and if you
do, yo'd have to put another envelope around the tokens with a new
registry (or mapping the CWT registry to that envelope).

> If you do not use a CWT, you may want some other form of identification of what the payload is about, and the COSE content-type header parameter (3) is one of them.

Right. So why did RFC8392 not use the COSE content type field but
invented its own claim key field ? Question for yet another WG (ACE) ? ;-))

Cheers
   Toerless

-- 
---
[email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 22 Jul 2021 19:57:19 +0200

> -> A CWT is a COSE object right ?

Yes, with an unprotected CWT claims set (UCCS) inside [1].

[1]: https://www.ietf.org/archive/id/draft-ietf-rats-uccs-01.html
(We are doing this the wrong way around…)

>   Except that the actual semantic of the cwt is in the CBOR claim key field.

That is not one field; the claim keys are map keys.

> every token in the drawer.

That is not a good strategy, as any token you present is disclosing some information and you only want to disclose that to someone that your overseeing principal authorizes to receive it.  So you better have a better grip on the tokens that you can hand out.

> invented its own claim key field ?

CWT for COSE what JWT is for JOSE.
No invention at all.

Grüße, Carsten