Thanks, Esko
I find it architecturally somewhat weird to have this "level skip":
Normally, if you have a container format, that container format itself
would have to indicate the type of its components, and you would not
need to or want to expose the type of any component outside of the container.
I guess COSE and its registries were designed this way because the fact that
applications may want to know about the payload type even before wanting
to bother about its signature. I can not quite build an example workflow though
to prove that need.
Personally, i would prefer to mandate the content-format even if
duplicate, just for any type of diagnostics that may not have access to
the whole stack into which the COSE object is embedded. Unless of course
size-concerns
significantly outweigh potential diagnostic benefits.
Cheers
Toerless
On Wed, Jul 21, 2021 at 07:58:58AM +0000, Esko Dijk wrote:
> Hi Toerless,
>
> > Is that a correct understanding how CoAP would work ?
>
> Agree, the content-format is stored as a single var-length uint in a CoAP
> Option (not part of the fixed header but one of the optional elements).
>
> > Now, there is in the COSE header also a parameter paramaeter called
> > "content type"
>
> In my implementation I don't use the 'content type' header in COSE because it
> is duplicate. The type is given at CoAP level already so there is no
> ambiguity, so the "SHOULD" in RFC 8152 doesn't apply.
> We may mention in the draft not to use this 'content type' for live-generated
> vouchers and voucher-requests. If the object is created to be transported
> over other ways (e.g. email, USB stick, etc) then I would opt for including
> that 'content type' possibly. Although the filename (*.vch) in that case will
> indicate the exact media type.
>
> > ... would be the case if we would not use TBD3 in CoAP for the COSE
> > message, but instead "18" to indicate only application/cose;
> > cose-type="cose-sign1" ID=18
>
> Correct, then there might be ambiguity w.r.t. other / future Voucher and
> Voucher Request formats that may be transported between Pledge and Registrar
> in operations on the *same* resource (e.g. /rv). But as long as such formats
> aren't defined it will also work in practice.
> For example my servers should also accept content-format 18 just as TBD3.
> So all in all I would say leaving out the 'content type' parameter always
> will just work and it will only be needed once a new content type is defined
> that also uses COSE_Sign1 encoding and that new type is used on BRSKI
> resources like /rv.
>
> Esko
>
> -----Original Message-----
> From: Toerless Eckert <t...@cs.fau.de>
> Sent: Tuesday, July 20, 2021 21:39
> To: draft-ietf-anima-constrained-vouc...@ietf.org; Carsten Bormann
> <c...@tzi.org>
> Cc: anima@ietf.org
> Subject: draft-ietf-anima-constrained-voucher COSE confusion
>
> Wrt to the discussion today at he Hackathon, i am trying to figure out
> how the header hierarchy for constrained voucher would work:
>
> We use a CoAP session.
> As a payload of CoAP, we indicate a COSE message, so
> somewhere in a CoAP header we have a (hopefully ?) binary field for
> the message type, and the value would be the TBD value to be assigned
> for cose vouchers in
> https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#content-formats
>
> e.g.:
>
> application/voucher-cose+cbor ID=TBD3
>
> Is that a correct understanding how CoAP would work ?
>
> Now, there is in the COSE header also a parameter paramaeter called
> "content type", and if i read RFC8152 correctly, that field SHOULD
> be present and i guess also have the value TBD3, so there is
> some duplication here. I am not so much worried about this,
>
> i just don't understand RFC8152 text "Applications SHOULD provide this header
> parameter if the content structure is potentially ambiguous", and i
> wonder if/how that could ever be the case. I can only imagine his
> would be the case if we would not use TBD3 in CoAP for the COSE
> message, but instead "18" to indicate only application/cose;
> cose-type="cose-sign1" ID=18.
>
> Cheers
> Toerless
--
---
t...@cs.fau.de
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
