I support the WG adoption of this document. It will be a useful component to
create a security solution for IoT devices. On the current or a future version
of this draft I can do a review, also.
Best regards
Esko Dijk
-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On
well-known URI is available that is usable without
discovery, just like EST RFC 7030 defines it for https.
The "ArbitraryLabel" only makes the URI longer.
best regards
Esko Dijk
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
.com//
coaps://www.example.com//ArbitraryLabel/
--
The suggestion by Peter to add references to the corresponding EST RFC 7030
sections is also good.
Regards
Esko
From: Panos Kampanakis (pkampana)
Sent: Wednesday, September 12, 2018 17:31
To: Esko Dijk ; ace@ietf.org
Subject: RE: ace-co
: Panos Kampanakis (pkampana)
Sent: Monday, September 17, 2018 19:12
To: Esko Dijk ; ace@ietf.org
Subject: RE: ace-coap-est: unclear definition of /.well-known/est URI
Hi Esko,
Good point. We made this change to ensure the text is clearer. You will see it
in the next iteration.
Thank you,
Panos
Esko
From: Peter van der Stok
Sent: Thursday, September 20, 2018 16:56
To: Michael Richardson
Cc: Esko Dijk ; Panos Kampanakis (pkampana)
; ace@ietf.org
Subject: Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI
Michael Richardson schreef op 2018-09-20 16:51:
I didn't
> I've seen it just return , but I guess if you want to return the
> port number, you have to return the hostname... <:61616/est> won't do?
The closest thing valid according to the ABNF definitions would be
But unfortunately CoAP by its RFC 7252 URI definition forbids using an empty
host (reg
> I've asked if discovery is always required, permitted, or encouraged.
Normally it is always encouraged to use discovery in favour of fixed URIs at
the server, to avoid specs squatting the URI namespace. But in our case the
/.well-known/est space is already assigned (RFC 7030) so we have to sup
Dnote" in the text is not so clear on what will happen.
Best regards
Esko Dijk
-Original Message-
From: Ace On Behalf Of Panos Kampanakis (pkampana)
Sent: Monday, September 17, 2018 18:56
To: Jim Schaad ; draft-ietf-ace-coap-...@ietf.org
Cc: 'ace'
Subject: Re: [Ace] Review
slow server can
acknowledge the request with a 2.31 code" -> 2.31 is not specified in RFC 7252.
Best regards
Esko Dijk
-Original Message-
From: Ace On Behalf Of Jim Schaad
Sent: Monday, January 14, 2019 05:03
To: ace@ietf.org
Subject: [Ace] WGLC for draft-ietf-ace-coap-est
The cha
Sent: Thursday, January 24, 2019 06:05
To: 'Michael Richardson' ; Esko Dijk
Cc: ace@ietf.org
Subject: RE: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded
devices
> -Original Message-
> From: Ace On Behalf Of Michael Richardson
> Sent: Wednesday,
action, that would contradict its purpose.
Best regards
Esko Dijk
-Original Message-
From: Ace On Behalf Of Michael Richardson
Sent: Thursday, January 24, 2019 16:59
To: Panos Kampanakis (pkampana) ; ace@ietf.org
Cc: Jim Schaad ; consulta...@vanderstok.org
Subject: Re: [Ace] FW: WGLC
content format TBD which encodes a multipart type
including a TBD287, so the client can use the Accept Option as normal to
request the wanted multipart type.)
Regards
Esko
Esko Dijk IoT Consultancy | Email/Skype:
esko.d...@iotconsultancy.nl<mailto:esko.d...@iotcon
uot;ace.est.skg";ct="62 280 284 281 TBD287"
NEW:
;rt="ace.est.skg";ct=62
Note that this format is now CoAP-correct but has the drawback that the client
can't see whether the optional TBD287 is supported or not in the /skg function.
Best regards,
Esko
Esk
cussion; see what people think about this issue.
Esko
-Original Message-
From: Michael Richardson
Sent: Thursday, February 14, 2019 15:38
To: Panos Kampanakis (pkampana)
Cc: Klaus Hartke ; Esko Dijk
; ace@ietf.org
Subject: Re: [Ace] ace-coap-est-08: using /skg with Accept Option set t
Hi Panos, Hannes,
Another reason for server-side keygen can be that an IT department/manager
wants it that way. There could be a policy that the keypairs for all domain
certificates must be created by the systems under direct control of the IT
department. (E.g. to comply with other policies or
then maybe a more
psychological requirement rather than technical. A powerful server with RTC
just sounds more capable to do private key generation than an IoT device, which
is why server-side keygen may be preferred ;)
Esko
From: Hannes Tschofenig
Sent: Tuesday, May 14, 2019 18:46
To: Esko
Dear authors,
In the draft both the paths /crt and /crts are used – this appears to be
incorrect. Should it /crts always ?
Best regards
Esko
Esko Dijk IoT Consultancy | Email/Skype:
esko.d...@iotconsultancy.nl<mailto:esko.d...@iotconsultancy
Thanks,
A few comments I had still on the discovery section - sorry to be late
post-WGLC with this:
- page 10 bottom mentions "management data" - should say "management
resources", or "EST resources" perhaps?
- page 10 bottom: " Upon success, the return payload will contain the root
resource o
better why this works.
Hope these comments can still be used for improvement of the spec. I will send
further review comments in a next email: still need to write these down.
Best regards
Esko
-Original Message-
From: Panos Kampanakis (pkampana)
Sent: Monday, May 20, 2019 17:31
To:
icies to recover from improper CSR requests."
-> should be "an EST-coaps server is expected to" ? Because this
specification and 10.1 describes the EST-coaps server, not a CA.
* Sections 5.1, 5.7, 10.2 : word "he" is used to refer to client or server.
Maybe this should
Hello Jim,
Thanks for your comments - the authors are now looking into these and we'll
reply again as soon as we have answers. I also copy this to the CoRE WG list;
as the draft targets the CoRE WG.
Esko
-Original Message-
From: Jim Schaad
Sent: Wednesday, May 29, 2019 00:45
To: dra
Hello Panos,
I noticed one sentence in Appendix A that seems inconsistent with the rest of
the I-D, or at least gives an incomplete view :
If the client had requested Content-
Format TBD287 (application/pkix-cert) by querying /est/skc, the
server would respond with a single DER binary c
Thanks, the proposed text is fine! Agree it is a minor item.
Esko
-Original Message-
From: Panos Kampanakis (pkampana)
Sent: Monday, February 17, 2020 17:47
To: Esko Dijk ; ace@ietf.org
Subject: RE: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt
Thank you for this Esko. Hmm, point
/ace-groupcomm+cbor
Content Coding: -
regards
Esko
-Original Message-
From: David Dong via RT
Sent: Friday, October 20, 2023 00:23
Cc: Esko Dijk ; ace@ietf.org;
har...@projectcool.de; c...@tzi.org; ja...@iki.fi; jaime.jime...@ericsson.com;
alexan...@ackl.io
Subject: [IANA #1284518] expert re
ange some reason/rationale needs to be provided.
Regards
Esko
-Original Message-
From: David Dong via RT
Sent: Friday, January 12, 2024 02:10
Cc: Esko Dijk ; har...@projectcool.de;
c...@tzi.org; ja...@iki.fi; jaime.jime...@ericsson.com; alexan...@ackl.io;
ace@ietf.org
Subject: [IANA
Dijk
Cc: garcia...@uniovi.es; ace@ietf.org
Subject: Re: [Ace] [IANA #1303039] expert review for draft-ietf-ace-wg-coap-eap
(core-parameters, CoAP Content-Formats)
Dear Esko,
Thank you for your comments.
Please, see responses inline.
El 12/1/24 a las 10:55, Esko Dijk escribió:
> Hello,
&g
Thanks, this is approved. We can allocate an available number, suggesting the
261-270 range.
Regards
Esko
-Original Message-
From: David Dong via RT
Sent: Friday, March 15, 2024 20:23
Cc: Esko Dijk ; alexan...@ackl.io; c...@tzi.org;
ja...@iki.fi; jaime.jime...@ericsson.com; har
Hi all, authors (cc),
Here's a first review of the document draft-ietf-ace-coap-est-oscore-05. This
is mostly based on my first read of the document; I didn't look yet into all
the details or possible implementations of this technology.
Overall it looks like a useful addition to the constrained-
th the matching
COSE CBOR tag"?
9.2.1
"Applications that use this media type: IoT applications sending security
tokens over HTTP(S) and other transports"
-> can already mention CoAP/CoAPs here ?
Best regards
Esko Dijk
-Original Message-
From: Ace [mailto:ace-boun...@
and a receiver MUST ignore the value of this field”.
Both are needed.
Best Regards
Esko
From: Samuel Erdtman [mailto:sam...@erdtman.se]
Sent: Wednesday, December 6, 2017 13:48
To: Esko Dijk
Cc: Benjamin Kaduk ; ace@ietf.org
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 Novemb
onfusing for developers. They might think
they need to implement something while the requirement actually asks them *not*
to implement something. Most developers would not bother to implement such
extra checks anyhow.
thanks
Esko
From: Mike Jones [mailto:michael.jo...@microsoft.com]
Sent: Frid
n I'm okay with it.
Esko
-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Carsten Bormann
Sent: Monday, December 11, 2017 22:59
To: Esko Dijk
Cc: Samuel Erdtman ; Mike Jones
; Benjamin Kaduk ; ace@ietf.org
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends
32 matches
Mail list logo
