Thanks Toerless,
I support this early allocation! One minor comment:
> Optional parameters: cose-type
Carsten also flagged this. This is a mistake in the registration text I
believe. Because the format we define already indicates COSE_Sign1 there is no
support for any other cose-type's need
Hello all,
I have run into the same issue and decided to check the RFCs on this behaviour.
Turns out, it is correct behaviour per specifications. See RFC5280 section
4.2.1.12.
If the EKU is present, it will restrict the allowed usage purposes of the
certificate to only those items listed in th
Hi,
There is already a "CoAP ping" described in RFC 7252 that can be used. It does
not access any resource, just the CoAP server endpoint at CoAP message layer.
As a side effect of this ping your DTLS stack will set up the connection which
is handy.
So I don't think we need a resource at / tha
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
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
We had interesting discussions yesterday about how to fix the media-type and
content-format registrations for CBOR-based anima vouchers.
I’m growing a bit tired of dispensing the ancient wizardry that is required
each time such a registration is needed, so I started writing it up:
https://cabo.
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.)
Working on IETF111 chair slides i just stumbled over one process step:
a) Dear authors of draft-richardson-anima-jose-voucher and ANIMA WG:
This is the IPR poll for draft-richardson-anima-jose-voucher
We need for each of you authors to make an IPR statement about the draft.
As applicable, for e
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
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
Esko Dijk wrote:
> There is already a "CoAP ping" described in RFC 7252 that can be
> used. It does not access any resource, just the CoAP server endpoint at
> CoAP message layer. As a side effect of this ping your DTLS stack will
> set up the connection which is handy.
I recalle
Carsten Bormann wrote:
> On 20. Jul 2021, at 23:19, Toerless Eckert wrote:
>>
>> Optional parameters: cose-type
> Ugh.
removed from git copy.
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Carsten Bormann wrote:
> We had interesting discussions yesterday about how to fix the
> media-type and content-format registrations for CBOR-based anima
> vouchers.
Thank you for your input, and for trying to remove yourself from the loop.
> I’m growing a bit tired of dispensin
Toerless Eckert wrote:
> Working on IETF111 chair slides i just stumbled over one process step:
> a) Dear authors of draft-richardson-anima-jose-voucher and ANIMA WG:
> This is the IPR poll for draft-richardson-anima-jose-voucher
> We need for each of you authors to make an IPR
>
>> https://cabo.github.io/cbor-media-types/draft-bormann-cbor-defining-media-types.html
>
>> Comments and PRs very welcome.
>
> I did find reading it invoked a new appreciation for Arcane Wizardry.
>
> Specifically, I found that sections 3 and 4 didn't tell me anything that I
> recognized as
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
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
>
>> 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
Henk Birkholz via Datatracker wrote:
> Reviewer: Henk Birkholz
Thank you for this review!
> (0) Title
> The title implies that this document defines a message or document called
> 'Constrained Voucher Artifacts' used in 'Bootstrapping Protocols'. The
first
> sentence contr
The following errata report has been submitted for RFC8366,
"A Voucher Artifact for Bootstrapping Protocols".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6646
--
Type: Technical
Reported by
On Thu, Jul 22, 2021 at 02:47:33AM +0200, Carsten Bormann wrote:
> >
> >> 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-leve
Toerless Eckert wrote:
> Working on IETF111 chair slides i just stumbled over one process step:
> a) Dear authors of draft-richardson-anima-jose-voucher and ANIMA WG:
> This is the IPR poll for draft-richardson-anima-jose-voucher
> We need for each of you authors to make an IPR s
Is there a way to use Olaf's "coap-client" to do the ping?
I don't see an option, and it also doesn't seem to be commonly built
with DTLS.
No, I have a three lines of code for doing a ping, from pledge; not from
coap_client
Peter
Michael Richardson schreef op 2021-07-21 21:36:
Esko Dijk w
23 matches
Mail list logo
