I support the addition of draft-selander-ace-coap-est-oscore in the Charter
as it introduces OSCORE with its advantages in constrained environments for
EST which is already standardized in EST-coaps in ACE.
As I have said before, I oppose the addition of CMPv2 over COAP in the
charter.
I oppose adoption.
IETF in the past has come up with SCEP, CMP, CMC and EST, all of them for the
most part doing the same thing with minor differences. I don’t think we need
two enrollment protocols to run over COAP. We should not repeat mistakes of the
past.
In ACE we have EST-coaps
and established, end-to-end
protection the sole motivating reason?
Rgs,
Panos
-Original Message-
From: Ace On Behalf Of Brockhaus, Hendrik
Sent: Wednesday, July 22, 2020 9:42 AM
To: Panos Kampanakis (pkampana) ; Benjamin Kaduk
; Michael Richardson
Cc: Mohit Sahni ; steffen.fr...@siemens.
Hi,
> Looking into Mohits draft, cmp-over-coap is much simpler than
est-over-coaps, as CMP does not need any binding to an underlying (D)TLS
handshake.
Not sure that is accurate. And EST does not bind to the tunnel protocol
either unless proof of possession is used. For now the cmp-over-coap
inary certificate.
That certificate would be in a multipart-core container specifically
in the case of a response to /est/skc query."
Let us know if you have any objections.
Rgs,
Panos
-Original Message-
From: Esko Dijk
Sent: Monday, February 17, 2020 3:15 AM
To: Panos Kampanakis
Sorry, forgot the git link
https://github.com/SanKumar2015/EST-coaps/issues?utf8=%E2%9C%93=is%3Aissue
+%22s+IESG%22
-Original Message-
From: Ace On Behalf Of Panos Kampanakis (pkampana)
Sent: Monday, January 06, 2020 1:12 PM
To: ace@ietf.org; i-d-annou...@ietf.org
Subject: Re: [Ace
Hello,
This iteration addresses all IESG reviews. More details on the feedback and
how we addressed it are in the git issues here
Rgs,
Panos
-Original Message-
From: Ace On Behalf Of internet-dra...@ietf.org
Sent: Monday, January 06, 2020 1:00 PM
To: i-d-annou...@ietf.org
Cc:
Hi Alexey,
> Just to clarify: the original EST URIs are prohibited in COAP-EST?
No we don't forbid them in the draft. We do not make them MTI either though.
The long URIs can be supported and they would be a non-default EST-coaps
resource that a server could support and a client could do
Hi Alexey,
This commit
https://github.com/SanKumar2015/EST-coaps/commit/77d65f0eb7a28282f363e5e48cd0d28970f9366e
should address your feedback. The full discussion is in
https://github.com/SanKumar2015/EST-coaps/issues/155
Let us know if it does not make sense.
Rgs,
Panos
Message-
From: Ace On Behalf Of Panos Kampanakis (pkampana)
Sent: Saturday, December 21, 2019 10:49 PM
To: Barry Leiba ; The IESG
Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com;
ace-cha...@ietf.org; ace@ietf.org
Subject: Re: [Ace] Barry Leiba's No Objection on draft-ietf-ace-coap
Message-
From: Ace On Behalf Of Panos Kampanakis (pkampana)
Sent: Thursday, December 19, 2019 11:50 PM
To: Alissa Cooper ; The IESG
Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com;
ace-cha...@ietf.org; ace@ietf.org
Subject: Re: [Ace] Alissa Cooper's No Objection on
draft-ietf-ace
Message-
From: Ace On Behalf Of Panos Kampanakis (pkampana)
Sent: Sunday, December 22, 2019 11:41 PM
To: Roman Danyliw ; The IESG
Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com;
ace-cha...@ietf.org; ace@ietf.org
Subject: Re: [Ace] Roman Danyliw's No Objection on draft-ietf-ace
Hi Magnus,
This commit
https://github.com/SanKumar2015/EST-coaps/commit/37f6337a3b389632c18b77d3c4d
b8f28aabe9b63 tries to address your feedback. Let us know if it does not
make sense.
Rgs,
Panos
-Original Message-
From: Ace On Behalf Of Panos Kampanakis (pkampana)
Sent: Friday
Hi Roman,
Thank you for the thorough review.
Please check the response to your feedback in
https://github.com/SanKumar2015/EST-coaps/issues/154 There we include the fixes
we will make and our thoughts on a couple of your comments.
Please let us know if you have any further objections.
Hi Adam,
Thank you for the feedback. For completeness, we are tracking it in a git issue
https://github.com/SanKumar2015/EST-coaps/issues/156
Good point about updating the Well-Known URIs to include [This RFC]
additionally to RFC7030. We will make sure we add this in the IANA
considerations.
Hi Barry,
Thank you for the thorough review. We are tracking your feedback and our
responses in a git issue https://github.com/SanKumar2015/EST-coaps/issues/153
We mostly confirm all your minor text changes and nit fixes. The TBD one we
will not fix as we are waiting on IANA.
Let us know if
Hi Alexey,
Thanks for the feedback.
We are tracking all your 4 comments and discussion points in a git issue in
https://github.com/SanKumar2015/EST-coaps/issues/155 There are 4 comments in
the issue, one for each of your points. The comments include all exchanged
information in this thread
Sent: Friday, December 20, 2019 4:34 AM
To: i...@ietf.org; Panos Kampanakis (pkampana)
Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com;
ace-cha...@ietf.org; ace@ietf.org
Subject: Re: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17:
(with DISCUSS)
Hi,
On Fri, 201
Thanks Magnus.
> The EST-coaps client MUST support
> Block1 only if it sends EST-coaps requests with an IP packet size
> that exceeds the Path MTU.
>
> I think the requirement for when Block1 is required to be supported in the
> above sentence is unclear. Is the intention to say: An EST-coaps
Hi Alissa,
Thank you for the feedback.
> "It is also RECOMMENDED that the Implicit Trust Anchor database used
> for EST server authentication is carefully managed to reduce the
> chance of a third-party CA with poor certification practices
> jeopardizing authentication."
>
> This strikes me
This version addresses Ben's recent feedback before it can go to IESG
evaluation.
Thanks Ben for keeping us honest.
Panos
-Original Message-
From: Ace On Behalf Of internet-dra...@ietf.org
Sent: Thursday, December 05, 2019 9:43 PM
To: i-d-annou...@ietf.org
Cc: ace@ietf.org
Subject:
Hi Ben,
Can you confirm if the diff
https://github.com/SanKumar2015/EST-coaps/commit/53933bb9f9365795f2302baef2e39709ae05
addresses your feedback? I will then re-upload it.
Thanks,
Panos
-Original Message-
From: Ace On Behalf Of Panos Kampanakis (pkampana)
Sent: Monday
rom: Benjamin Kaduk
Sent: Tuesday, November 12, 2019 6:06 PM
To: Panos Kampanakis (pkampana)
Cc: Yaron Sheffer ;
draft-ietf-ace-coap-est@ietf.org; ace@ietf.org
Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15
Hi Panos,
On Wed, Oct 16, 2019 at 03:06:01PM +0000, Panos Kampana
Hi,
This iteration addresses Yaron's secdir review. Thank you for the thorough
feedback Yaron.
The summary of the fixes is here
https://github.com/SanKumar2015/EST-coaps/issues/152
The diff is here
https://tools.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-16.txt
Rgs,
Panos
Hi Yaron,
Thank you for the thorough review and feedback.
To make sure I don't miss any of your comments over an email thread, I track
all your feedback in git issue 152
https://github.com/SanKumar2015/EST-coaps/issues/152 There I tried to address
all your comments and question and clarify
Thanks David. Done. I replaced the RFC7525 references with BCP195.
Should I upload or will there be more Gen-ART reviews?
-Original Message-
From: Ace On Behalf Of David Schinazi via Datatracker
Sent: Sunday, October 06, 2019 12:49 AM
To: gen-...@ietf.org
Cc:
Hello,
The v15 iteration addresses Ben K.'s latest feedback in response to the fixes
that went in after his AD review. Thank you for the detailed feedback Ben.
The diff from v14 is here
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-15
I think it could move to the next stage now.
/ff5b303781231e34571352cb07fb895d5ecab791
I will reupload early next week. Please check out the issue in case you have
further comments.
Panos
-Original Message-
From: Ace On Behalf Of Benjamin Kaduk
Sent: Monday, September 23, 2019 6:48 PM
To: Panos Kampanakis (pkampana)
Cc: Peter van der Stok ; Jim Schaad
; draft
Hi everyone,
This iteration addresses comments we received from Ben's AD Review. Thanks Ben.
The summary of all comments and what went into the text after the discussions
in the list is in the git issue
https://github.com/SanKumar2015/EST-coaps/issues/150
Rgs,
Panos
-Original
Otherwise we
will upload at the end of the week.
Rgs,
Panos
-Original Message-
From: Ace On Behalf Of Panos Kampanakis (pkampana)
Sent: Tuesday, September 10, 2019 12:18 AM
To: Jim Schaad ; 'Michael Richardson'
Cc: draft-ietf-ace-coap-est@ietf.org; 'Benjamin Kaduk' ;
ace@ietf.
Hi Jim,
We are tracking all of Ben's feedback here
https://github.com/SanKumar2015/EST-coaps/issues/150
The fixes that have gone in the draft so far are after each comment. There are
still some that we still need to update after the threads converged.
Panos
-Original Message-
Hi all,
This iteration fixes the nits and feedback provided by Esko in 5/21 and 5/28.
The comments and their fixes are discussed in two git issues
- https://github.com/SanKumar2015/EST-coaps/issues/145
- https://github.com/SanKumar2015/EST-coaps/issues/146
The diff from the previous
if there is anything else.
Panos
-Original Message-
From: Ace On Behalf Of Esko Dijk
Sent: Tuesday, May 28, 2019 6:31 AM
To: Panos Kampanakis (pkampana) ; ace@ietf.org
Subject: Re: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt / additional
review comments
Hello,
Thanks
Original Message-----
From: Ace On Behalf Of Esko Dijk
Sent: Tuesday, May 28, 2019 6:31 AM
To: Panos Kampanakis (pkampana) ; ace@ietf.org
Subject: Re: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt / additional
review comments
Hello,
Thanks for the update! First, regarding the changes:
*
g interops/code;
was a specific CoAP library used that exhibits this behavior? I would be
interested to understand 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
dundant so I only kept "Throughout this document the example root
resource of /est is used."
Will reupload the next iteration in a few days.
Rgs,
Panos
-Original Message-
From: Esko Dijk
Sent: Monday, May 20, 2019 2:31 AM
To: Panos Kampanakis (pkampana) ; ace@ietf.org
Cc: draft-ietf-
Hi all,
This latest update addresses feedback while in WGLC"
- the comments by Hannes and Esko related to RNG and server-side key gen. It
aims to prevent misunderstandings that random numbers are not needed any more
if server-side key gen is used.
- the nits with "/crt" instead of "/crts"
Good catch Esko. Thanks.
We had three leftover “/crt” that should have been “/crts”. Will be fixed in
the iteration to be submitted tomorrow.
From: Ace On Behalf Of Esko Dijk
Sent: Thursday, May 16, 2019 5:28 AM
To: ace@ietf.org; draft-ietf-ace-coap-...@ietf.org
Subject: [Ace] Use of /crt vs
-quality random
numbers is therefore important.
[ … ]
~
I am planning to reupload by the end of the week.
Rgs,
Panos
From: Hannes Tschofenig
Sent: Tuesday, May 14, 2019 3:28 PM
To: Esko Dijk ; Panos Kampanakis (pkampana)
; ace@ietf.org
Subject: RE: [Ace] EST over CoAP: Randomness
Esko
The draft is not recommending against RNGs in any way and hopefully there will
be no room for such misunderstandings in the updated text.
Panos
From: Ace On Behalf Of Damm, Benjamin
Sent: Wednesday, May 15, 2019 10:29 AM
To: Hannes Tschofenig ; Paul Duffy (paduffy)
; ace@ietf.org
Subject: Re:
Sent: Friday, May 10, 2019 4:58 AM
To: Panos Kampanakis (pkampana) ; ace@ietf.org
Subject: RE: [Ace] EST over CoAP: Randomness
Hi Panos,
I had argued earlier that this feature shouldn't be in the draft but it seems
that I will not get there.
Hence, I believe it would be better to first shorten t
Thanks Hannes.
Before I try to address it, can you help me understand what you are proposing.
To amend this paragraph maybe?
-Original Message-
From: Ace On Behalf Of Hannes Tschofenig
Sent: Thursday, May 09, 2019 10:43 AM
To: ace@ietf.org
Subject: [Ace] EST over CoAP: Randomness
Hi
This iteration addresses the recent WGLC feedback from Klaus and Jim. A summary
of the issues addressed can be found here
https://github.com/SanKumar2015/EST-coaps/issues?utf8=%E2%9C%93=is%3Aissue+%22WGLC+review+2%2F27%2F2019%22
It should also cover all other feedback we have received as
D.
Panos
-Original Message-
From: Benjamin Kaduk
Sent: Sunday, February 24, 2019 7:08 PM
To: Panos Kampanakis (pkampana)
Cc: Klaus Hartke ; Jim Schaad ;
ace@ietf.org
Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est
On Fri, Feb 22, 2019 at 09:00:05PM +0000, Panos Kampanakis (pkampa
Hi Klaus,
Thanks for the thorough review.
All your issues identified are tracked here
https://github.com/SanKumar2015/EST-coaps/issues?utf8=%E2%9C%93=is%3Aissue+%22Klaus+WGLC%22
. We tried to address all of them. The fixes we are putting in are spelled out
in the github issues themselves.
OK, I was clearly misunderstanding what you were proposing.
I can see that second URI working fine without affecting existing systems. Will
update the draft.
-Original Message-
From: Jim Schaad
Sent: Thursday, February 21, 2019 10:55 PM
To: Panos Kampanakis (pkampana) ; 'Carsten
query type may be OK, but I can
see Carsten and Klaus' point. We can just keep one cert content type in the
multipart, that simplifies it.
Rgs,
Panos
-Original Message-
From: Jim Schaad
Sent: Thursday, February 21, 2019 6:35 PM
To: 'Carsten Bormann'
Cc: Panos Kampanakis (pkampana) ; 'a
> This is why I would prefer doing something like "/est/skg" and "/est/skg/yyy".
Not sure I am following. Are these two request URIs? Or in the discovery
response?
-Original Message-
From: Jim Schaad
Sent: Thursday, February 21, 2019 4:54 PM
To: Panos Kampanaki
te values are the accepted values by the server in the "Accept"
option.
-Original Message-----
From: Carsten Bormann
Sent: Wednesday, February 20, 2019 8:11 PM
To: Panos Kampanakis (pkampana)
Cc: Jim Schaad ; ace@ietf.org; Klaus Hartke
; draft-ietf-ace-coap-...@ietf.org
Subject: Re: [A
Thanks Jim. We have addressed all of them in the upcoming next iteration.
We also have addressed Klaus' feedbacks and will send a response to him this
week.
The only issue left is the embedded content types which is being discussed as
you know.
Panos
-Original Message-
From: Ace
Hi Jim,
Thank you. Sorry I couldn't make it to the CORE interim meeting.
I see the challenge with content-format ID explosion in option c. So I agree
that in the long run, there needs to be a long-term solution and option b seems
the best for the general case.
There are challenges with
Hi Jim,
About
> 4. The query in section 5.1 to a resource directory is not correct. It
> would not go to /.well-known/core but to /rd-lookup (or what ever name is
> used by the RD). If this is not intended to be an RD query, then the
> sentence about it above can be omitted.
> 5.
r
for the client to define the supported formats of the requested
resource/response is a good one.
-Original Message-
From: Ace On Behalf Of Klaus Hartke
Sent: Tuesday, February 12, 2019 4:36 PM
To: Panos Kampanakis (pkampana)
Cc: Esko Dijk ; ace@ietf.org
Subject: Re: [Ace] ace-coap-est
Hi all,
The -08 version of the draft
https://tools.ietf.org/html/draft-ietf-ace-coap-est-08 addresses all comments
we received so far in the WGLC. It also simplifies parts of the text to make
easier to read, moves a couple of sections in more suitable order and fixes
nits and typos.
Thanks
es. I created new github issues for those.
Panos
-Original Message-
From: Jim Schaad
Sent: Monday, January 28, 2019 4:37 PM
To: Panos Kampanakis (pkampana) ; ace@ietf.org
Subject: RE: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07
Clipping out things which are not issues:
>
Hello,
The -07 version of draft-ietf-ace-coap-est addresses all feedback we have
received to date and updates all the examples to include more realistic
constrained environment EST-coaps message transactions.
It is ready for WGLC, as discussed in IETF-103.
Rgs,
Panos
-Original
cacerts.
Panos
-Original Message-
From: Hannes Tschofenig
Sent: Wednesday, December 12, 2018 11:01 AM
To: Panos Kampanakis (pkampana) ; Michael Richardson
; ace@ietf.org; an...@ietf.org
Cc: Peter van der Stok ; Max Pritikin (pritikin)
Subject: RE: est-coaps clarification on /att
ember 11, 2018 5:22 PM
To: Panos Kampanakis (pkampana) ; ace@ietf.org;
an...@ietf.org
Cc: Peter van der Stok ; Max Pritikin (pritikin)
Subject: Re: est-coaps clarification on /att and /crts
* PGP Signed by an unknown key
Panos Kampanakis (pkampana) wrote:
> I thought about this f
in
Constrained-BRSKI/voucher, but not taken lightly.
Rgs,
Panos
-Original Message-
From: Michael Richardson
Sent: Tuesday, December 11, 2018 11:29 AM
To: ace@ietf.org; an...@ietf.org
Cc: Panos Kampanakis (pkampana) ; Peter van der Stok
; Max Pritikin (pritikin)
Subject: est-coaps
wants to advertise a different port then we
would need the full URI with the port.
From: Peter van der Stok [mailto:stokc...@bbhmail.nl]
Sent: Monday, September 24, 2018 4:12 AM
To: Esko Dijk
Cc: Michael Richardson ; Panos Kampanakis (pkampana)
; consulta...@vanderstok.org; ace@ietf.org
Subject: Re
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
-Original Message-
From: Esko Dijk [mailto:esko.d...@iotconsultancy.nl]
Sent: Saturday, September 15, 2018 10:30 AM
To: Panos Kampanakis (pkampana) ; ace
Hi Jim,
Trying to close on this one and update the draft if necessary.
> [JLS] I do not believe that the wrapping of content with the CBOR binary
> text wrapping is needed at this point. If that is needed for the multi-part
> wrapping, then it is the job of the multi-part wrapping to deal
Hi Hannes,
Thank you for the text. The 15.4 was only serving only as a motivation usecase.
We revamped the Intro similar to what you suggested. It will be fixed in the
next iteration.
Panos
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Tuesday, May 15, 2018 5:34
Considerations.
From: Hannes Tschofenig [mailto:hannes.tschofe...@arm.com]
Sent: Tuesday, May 15, 2018 4:27 AM
To: Panos Kampanakis (pkampana) <pkamp...@cisco.com>; ace@ietf.org
Subject: RE: EST over CoAP
Hi Panos,
I would say forget class 1 devices when you want to use public key crypto.
not incur significant
workload to the endpoint itself.
Rgs,
Panos
From: Mohit Sethi [mailto:mohit.m.se...@ericsson.com]
Sent: Tuesday, May 15, 2018 1:37 AM
To: Panos Kampanakis (pkampana) <pkamp...@cisco.com>; Hannes Tschofenig
<hannes.tschofe...@arm.com>; ace@ietf.org
Subject: R
some of these comments.
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, May 14, 2018 10:14 AM
To: Panos Kampanakis (pkampana)
<pkamp...@cisco.com<mailto:pkamp...@cisco.com>>;
ace@ietf.org<mailto:ace@ietf.org>
Subject: Re: [Ace] EST over CoAP
Hi Hannes,
To address your question about server-side key gen, below is the explanation we
have put in the draft already and will be in the next iteration
~
Constrained devices sometimes do not have the necessary hardware to
generate statistically random numbers for private
+1
Should consider analysis and recommendations by NIST’s LWC project too
https://www.nist.gov/programs-projects/lightweight-cryptography
Panos
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, March 19, 2018 7:15 AM
To: John Mattsson
Hi Hannes,
I think the current draft offers that. The BRSKI EST APIs are not mandatory to
implement by any means. The bindings of just the EST (RFC7030) APIs explained
in the doc would suffice. If you are saying that the current doc is too
complicated, may that is something that can be
One correction: 1024-bit RSA/DSA is not the same security level as 256-bit
curve ECDSA or Ed25519. To compare apples to apples you would need 3072-bit
RSA/DSA sigs which ends up being far worse in terms of sig size and performance.
Agreed that symmetric group key auth has plenty of limitations.
Hi Dan,
So if I understand this correctly, the intention of this draft is to describe
how COAP header fields, options and data can be protected with DTLS (hence DTLS
record) regardless of the key exchange mechanism. Is it intended as an
alternative to OSCOAP/EDHOC?
Thanks,
Panos
-Original
Hi Michael,
This are interesting good points.
IMO, draft-pritikin-coap-bootstrap/draft-vanderstock-core-coap-est do not
necessarily need to define one transport mechanism. COAPS (over DTLS) is one
obvious option but running over OSCOAP with EDHOC is another. One of the goals
of these drafts
72 matches
Mail list logo
