Esko Dijk wrote:
> object is a Voucher/VR. So to be compliant to the draft I can remove
> support for cf=18 as soon as TBD3 is allocated. I still don't see how
> cf=18 could be 'wanton extension of the protocol' as it is just using
> CoAP/COSE defined mechanisms that apparently ar
> Yes I read the IETF specs and then implement my idea of what these are trying
> to say. It helps if more people are looking at it, as we do in this case :)
> to avoid interpretation errors.
> From what I read, a COSE_Sign1 object can be adequately described by cf=18 so
> that's what I implem
o Dijk
Cc: draft-ietf-anima-constrained-vouc...@ietf.org; Toerless Eckert
; anima@ietf.org
Subject: Re: [Anima] draft-ietf-anima-constrained-voucher COSE confusion
On 2021-07-22, at 10:23, Esko Dijk wrote:
>
> be liberal in what it accepts
Well, Postel’s principle doesn’t apply to wanton
ten Bormann
Sent: Thursday, July 22, 2021 10:39
To: Esko Dijk
Cc: draft-ietf-anima-constrained-vouc...@ietf.org; Toerless Eckert
; anima@ietf.org
Subject: Re: [Anima] draft-ietf-anima-constrained-voucher COSE confusion
On 2021-07-22, at 10:23, Esko Dijk wrote:
>
> be liberal in what
Hi,
To add my few words,
I am a proponent to explicitly state that the payload is a voucher and
its signature production.
Actually, my code decides what routines to invoke on the basis of that
information.
Peter
Carsten Bormann schreef op 2021-07-22 10:39:
On 2021-07-22, at 10:23, Esko Dij
On 2021-07-22, at 10:23, Esko Dijk wrote:
>
> be liberal in what it accepts
Well, Postel’s principle doesn’t apply to wanton extension of the protocol (~
somebody might decide to do something different from the standard, so I’ll
implement my idea of what that could be). If it says you need to
Cc: Toerless Eckert ;
draft-ietf-anima-constrained-vouc...@ietf.org; anima@ietf.org
Subject: Re: [Anima] draft-ietf-anima-constrained-voucher COSE confusion
>
>> Now, there is in the COSE header also a parameter paramaeter called "content
>> type"
>
> In my implem
>
>> 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.
It is not: the REST-level (here CoAP) Content-Type is the media-type of the
whole thing (as packaged in
Toerless Eckert wrote:
> 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
Esko Dijk wrote:
> 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 implementa
On 2021-07-21, at 18:27, Toerless Eckert wrote:
>
> I find it architecturally somewhat weird to have this "level skip”:
Depending on the key and its usage, you may want to include the context in the
signing input that this is a voucher. So that would support Toerless’ unease.
Grüße, Carsten
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
Or you can go the other way around, go for tag 18, put a content-format number
that you registered (along a media-type) for an *unprotected* voucher (payload)
into the protected header. (You might still want a content-format number/media
type for the entire voucher, but you may not need a tag.)
On 2021-07-21, at 09:58, Esko Dijk wrote:
>
> 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.
Probably not needed:
https://www.ietf.org/archive/id/draft-ietf-cbor-file-magic-02.html#name-cbor
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
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
16 matches
Mail list logo
