Subject: [Ace] draft-vanderstok-core-coap-est-00

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 23 Jan 2017 09:10:14 +0100

Hi Peter, Hi Sandeep,

thanks for putting this document together.

I read through it and have some high-level questions regarding the
envisioned scope and purpose of the document.

The abstract, the introduction and the references suggest that the
proposed mechanism is suitable for an IEEE 802.15.4 mesh network using
6lowpan in context of ANIMA using public key-based crypto only.

This sounds like a lot of constraints and I wonder whether this focus is
just a result of your personal interest or whether you believe this work
cannot just be a new transport for EST.

EST itself makes many of the features of the protocol optional already
and there are essentially only two functions that really have to be
implemented, namely

 * Simple PKI messages (using PKCS#10)
 * CA certificate retrieval

Do you believe that those two features are the onces that should be
mandatory to implement or is there less? Is there more?

How much text from other RFCs should be replicated in this document,
particularly from the EST RFC?

Wouldn't it be useful to refer to RFC 7925 instead of writing new text
for the use of DTLS security?

Do you have some early implementation experience with the suggested
approach?

Ciao
Hannes

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 25 Jan 2017 06:32:03 +0000

Hi Hannes,

Thank you. Let me try to address some of your questions.

> This sounds like a lot of constraints and I wonder whether this focus is just a result of your personal interest or whether you believe this 
work cannot just be a new transport for EST.

EST is used in ANIMA's BRSKI used for bootstrapping endpoints. We have a few usecases that call for running EST/BRSKI over COAP as an consistent common protocol in some constrained environments. So that is how this draft was started.

> Do you believe that those two features are the ones that should be mandatory to implement or is there less? Is there more?

cacerts, enroll, reenroll and ANIMA BRSKI's voucherrequest, voucher_status are probably going to be the MTI.

> How much text from other RFCs should be replicated in this document, particularly from the EST RFC?

Good point. We should clean up repetitions from other drafts.

> Wouldn't it be useful to refer to RFC 7925 instead of writing new text for the use of DTLS security?

Good point. There will be some more EST related DTLS explanations (for example POP) in the next iteration, but leveraging RFC7925 and clean up overlapping text is also important

> Do you have some early implementation experience with the suggested approach?

Indeed. The Nexus Group and SICS have an initial implementation.

Rgs,
Panos

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Monday, January 23, 2017 3:10 AM
To: [email-masked]
Subject: [Ace] draft-vanderstok-core-coap-est-00

Hi Peter, Hi Sandeep,

I read through it and have some high-level questions regarding the envisioned scope and purpose of the document.

The abstract, the introduction and the references suggest that the proposed mechanism is suitable for an IEEE 802.15.4 mesh network using 6lowpan in context of ANIMA using public key-based crypto only.

This sounds like a lot of constraints and I wonder whether this focus is just a result of your personal interest or whether you believe this work cannot just be a new transport for EST.

EST itself makes many of the features of the protocol optional already and there are essentially only two functions that really have to be implemented, namely

Do you believe that those two features are the onces that should be mandatory to implement or is there less? Is there more?

How much text from other RFCs should be replicated in this document, particularly from the EST RFC?

Wouldn't it be useful to refer to RFC 7925 instead of writing new text for the use of DTLS security?

Do you have some early implementation experience with the suggested approach?

Ciao
Hannes