Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 6 Feb 2019 18:21:41 +0000

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 to everyone that provided feedback and mostly Jim and Esko for their thorough reviews.

For a summary of the issues received in WGLC and how they were addressed, refer to https://github.com/SanKumar2015/EST-coaps/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aclosed+WGLC 

Let us know if there is more feedback.

Rgs,
Panos

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Jim Schaad
Sent: Tuesday, January 29, 2019 12:59 AM
To: [email-masked]
Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est

This message concludes the last call for this document.  The authors are requested to create and post a new document addressing the issues that were raised.

Jim

> -----Original Message-----
> From: Ace <[email-masked]> On Behalf Of Jim Schaad
> Sent: Sunday, January 13, 2019 8:03 PM
> To: [email-masked]
> Subject: [Ace] WGLC for draft-ietf-ace-coap-est
> 
> The chairs believe that the EST over CoAP draft is nearing the point 
> it
should
> be sent to the IESG for publication.  We are therefore going to have a 
> Working Group Last Call on this document.  WGLC will until 29th of 
> this month.  Please review the document and send comments both 
> positive and negative to the list about its state.
> 
> Jim & Roman
> 
> 
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

_______________________________________________
Ace mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ace

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 12 Feb 2019 18:38:14 +0100

Jim Schaad wrote:
> The chairs believe that the EST over CoAP draft is nearing the point it
> should be sent to the IESG for publication.  We are therefore going to have
> a Working Group Last Call on this document.  WGLC will until 29th of this
> month.  Please review the document and send comments both positive and
> negative to the list about its state.

I've performed a quick review of draft-ietf-ace-coap-est-08. Sorry for
being late to the party.

2. "Therefore, this specification utilizes DTLS [RFC6347], CoAP
[RFC7252] and UDP instead of TLS [RFC8446], HTTP [RFC7230] and TCP."
-- Is there a technical reason why EST could not be done over CoAP
over TCP, TLS, WebSockets, or SMS?

I understand that it was fashionable at some point to fork a protocol
like HTTP, layer some stuff on top of it and call it a new protocol.
However, I would strongly recommend that EST-coaps is presented as an
application that is strictly layered on top of CoAP and doesn't define
its own custom protocol stack.

4. -- Is this section about the generated certificates or the DTLS
connection between the client and the server? If the latter, this
section is weird, because RFC 7252 already does define MTI cipher
suites and extensions, and I see no reason why an application layered
on top of CoAP needs to restate all of that.

4. "The authentication of the EST-coaps client MUST be with a client
certificate in the DTLS handshake." -- Why? Why can't a client
communicate with a server using any other secure mechanism with client
authentication? Or is this just the MTI mechansim?

5.1. The use of the well-known path "/.well-known/est" seems to follow
the letter of BCP 190 but not the spirit. I don't see any reason why a
well-known path is needed here. In fact, as the section emphasizes,
short paths are important and an implementation will there likely want
to do the "/.well-known/core"-based discovery of URIs. I would
recommend that the entire use of "/.well-known/est" is dropped.

5.1. "Arbitrary Labels are usually defined and used by EST CAs in
order to route client requests to the appropriate certificate
profile." -- I assume that a client needs to construct URIs from the
well-known path "/.well-known/est", the Arbitrary Label and one of the
suffixes. How does a client determine which Arbitrary Label to use?

5.1. "The EST-coaps server URIs, obtained through discovery of the
EST-coaps root resource(s) as shown below, are of the form:" -- If a
client discovers the URIs from "/.well-known/core" (annotated with
"ace.est.crts", "ace.est.sen", etc.), is this table 1 still needed? If
not, I would recommend that only the 'rt'  values are standardized
("ace.est.crts", "ace.est.sen", etc.) and all paths are left to the
implementation, in accordance with BCP 190.

5.1. "Clients and servers MUST support the short resource URIs. The
corresponding longer URIs from [RFC7030] MAY be supported." -- Does
this provide any benefit or is it just to annoy implementers? Like, we
can have short paths, we can have long paths, we cannot decide, so
let's have ALL OF THEM!

5.1. "In the context of CoAP, the presence and location of (path to)
the management data are discovered by sending a GET request to
"/.well-known/core" including a resource type (RT) parameter with the
value "ace.est" -- I understand that EST defines the operations on the
resources labeled with annotated with "ace.est.crts", "ace.est.sen",
etc. but I don't understand what I can do with a resource that is
annotated with "ace.est".

5.1. "The first line of the discovery response above MUST be included.
The five consecutive lines after the first MAY be included." -- When
would I include what?

5.1. "The return of the content types allows the client to choose the
most appropriate one." -- Does the example actually match what a
server returns? E.g., does ct="62 280 284 281 TBD287" mean that a
server actually returns a TBD287 representation or would it always be
a 62 (multipart) representation that happens to contain a TBD287
representation?

5.1. "Port numbers, not returned in the example, are assumed to be the
default numbers 5683 and 5684 for CoAP and CoAPS respectively" -- No
need to make any assumptions. This is exactly what RFC 7252 specifies.
Please don't make any normative statements that just repeat (or
contradict) what RFC 7252 says.

5.1. "Discoverable port numbers MAY be returned in the <href> of the
payload [I-D.ietf-core-resource-directory]." -- What does this mean?
And what does Resource Directory have to do with EST?

5.1. " The server MUST support the default /.well-known/est server
root resource and port 5684." -- As said above, I would drop this
entirely.

5.1. "Resource discovery is necessary when the IP address of the
server is unknown to the client." -- Assuming that "resource
directory" refers to "/.well-known/core"-based discovery of URIs, then
this is wrong. If the IP address of a server is not known, then a
client cannot retrieve the "/.well-known/core" of that server.

5.2. "Table 2 specifies the mandatory-to-implement or optional
implementation of the est-coaps functions." -- How does a client
discover which functions are implemented?

5.3. "Content-Format TBD287 can be used in place of 281" -- It's a bit
difficult to see what TBD287 and 281 mean without scrolling all the
way down and scrolling back up. Maybe include the table here to make
the section easier to read?

5.3. "If an Accept Option is not included in the request, the client
is not expressing any preference and the server SHOULD choose format
281.  If the preferred Content-Format cannot be returned, the server
MUST send a 4.06 (Not Acceptable) response, unless another error code
takes precedence for the response [RFC7252]." -- Please don't make any
normative statements that repeat (or contradict) what RFC 7252 says.

5.3. "*application/multipart-core*" -- Formatting missing?

5.3. "The collection is encoded as a CBOR array [RFC7049] with an even
number of elements. ..." -- This is already described in
[I-D.ietf-core-multipart-ct]. Is there any reason why the text needs
to be duplicated?

5.4. "All EST-coaps messages expect a response from the server, thus
the client MUST send the requests over confirmable CON CoAP messages."
-- The use of confirmable messages for requests is completely
unrelated to whether a response is expected or not. Also, it is
entirely inappropriate for an application layered on top of CoAP to
mandate the message type.

5.4. "The Ver, TKL, Token, and Message ID values of the CoAP header
are not affected by EST." -- And it would be entirely inappropriate if
they were. So I'm not sure what to do with this information.

5.4. "The CoAP Options used are Uri-Host, Uri-Path, Uri-Port,
Content-Format, Accept and Location-Path." -- Of course, a server must
be prepared to receive requests that include other kinds of options
(such as "ETag" or "If-Match") and handle these in accordance to RFC
7252.

5.4. "The CoAP Options used are Uri-Host, Uri-Path, Uri-Port,
Content-Format, Accept and Location-Path." -- The Block options seem
to be missing.

5.4. "The Uri-Host and Uri-Port Options are optional." -- No, these
options are not optional. They just can be encoded very efficiently
(in 0 bytes) if they happen to have their default value.

5.4. "They are usually omitted as the DTLS destination and port are
sufficient." -- No. The default values of the options are the IP
destination address and UDP port, respectively (in CoAP-over-UDP).

5.4. "Alternatively, if a UDP port to a server is blocked, someone
could send the DTLS packets to a known open port on the server and use
the Uri-Port to convey the intended port he is attempting to reach."
-- Where is that coming from? Sounds extremely weird.

5.5. "Response code HTTP 202 Retry-After that existed in EST" -- HTTP
doesn't have response codes. And there is no status code named
"Retry-After" in HTTP.

5.5. "Moreover, if the Content-Format requested in the client Accept
Option, is not supported the server MUST return a 4.06 (Not
Acceptable), unless another error code takes precedence for the
response." -- Please don't make any normative statements that repeat
(or contradict) what RFC 7252 says.

5.7. "In particular, a slow server can respond to an EST-coaps
enrollment request with an empty ACK with code 0.00, before sending
the certificate to the server after a short delay." -- ...before
sending the certificate to the *client*?

5.7. "After a delay of Max-Age, the client SHOULD resend the identical
CSR to the server." -- Just for my understanding: Does the submission
of a specific CSR always lead to the same output, or can it happen
(e.g., if the client submits an identical CSR weeks or months later)
that the client would get a different output?

5.7. "... or the client abandons for other reasons." -- Does the
client need to signal in some way when it wants to abandon?

5.8. "containing a CBOR array with four items Section 5.3" -- Missing
word between 'items' and 'Section'

5.8. "containing a CBOR array with four items Section 5.3" -- Do the
two representations (each consisting of two CBOR array items) have to
be in a particular order or can they appear in any order?

6. "DTLS Transport Protocol" -- This section seems to have the same
topic as section 4. Merge section 4 into section 6?

6. "In a constrained CoAP environment, endpoints can't always afford
to establish a DTLS connection for every EST transaction." -- I'm not
aware of any requirement that says CoAP clients must establish a new
DTLS connection for every request...

6. "To alleviate this situation, an EST-coaps DTLS connection MAY
remain open for sequential EST transactions." -- An application
layered on top of CoAP shouldn't mandate a particular way in which
DTLS is used.

8. "Parameters" -- An application layered on top of CoAP shouldn't
mandate CoAP congestion control parameters.

10.2. "This EST resource is used to query and return the supported EST
resources of a CoAP server." -- Is there any specification for how to
query and return the supported EST resources?

I didn't review the appendices.

Klaus

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Fri, 22 Feb 2019 21:00:05 +0000

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&q=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. The actual latest version of the draft is https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-coap-est.txt 

After proof reading the draft one more time we will upload early next week. 

Below I am answering some of the questions you asked in your review. 

> 4. -- Is this section about the generated certificates or the DTLS connection between the client and the server? If the latter, this section is weird, because RFC 7252 already does define MTI cipher suites and extensions, and I see no reason why an application layered on top of CoAP needs to restate all of that.

This section describes how the (D)TLS profile defined in RFC7925 is used by EST-coaps. It was asked by the original ACE co-chair to show conformance with ACE profiles.  It touches on the client server authentication, the tunnel ciphersuites. It explains how the EST-coaps data exchange is secured thereby preventing eavesdropping, tampering, and message forgery. We wanted to spell out for implementers which parts of RFC7925 they should take into consideration instead of just pointing them to RFC7925 or RFC7252 etc. 

> 4. "The authentication of the EST-coaps client MUST be with a client certificate in the DTLS handshake." -- Why? Why can't a client communicate with a server using any other secure mechanism with client authentication? Or is this just the MTI mechansim?

The issue is that EST mandates HTTP Basic or Digest Auth and/or client cert auth. HTTP Auth is not defined for COAP application as far as we know. So, for EST-coaps, the only viable authentication method is mutual cert auth. Other client auth methods could be defined, but are outside the scope of this draft. 
 
> 5.1. "Arbitrary Labels are usually defined and used by EST CAs in order to route client requests to the appropriate certificate profile." -- I assume that a client needs to construct URIs from the well-known path "/.well-known/est", the Arbitrary Label and one of the suffixes. How does a client determine which Arbitrary Label to use?

That is configured on the client out of band depending on the CA that generates the certs. It is outside the scope of EST or EST-coaps. 

> 5.1. "The EST-coaps server URIs, obtained through discovery of the EST-coaps root resource(s) as shown below, are of the form:" -- If a client discovers the URIs from "/.well-known/core" (annotated with "ace.est.crts", "ace.est.sen", etc.), is this table 1 still needed? If not, I would recommend that only the 'rt'  values are standardized ("ace.est.crts", "ace.est.sen", etc.) and all paths are left to the implementation, in accordance with BCP 190.

We intend to require /.well-known URIs so that resource discovery is not mandatory for pre-configured client deployments. Discovery is optional when non-default URIs are needed to save URI space. Feel free to check the text in https://github.com/SanKumar2015/EST-coaps/issues/123 where I edited the resource discovery text to make it clearer. 

> 5.1. "Discoverable port numbers MAY be returned in the <href> of the payload [I-D.ietf-core-resource-directory]." -- What does this mean?

We needed a way to be able tell the client that the resource is hosted on another port but the reference to  I-D.ietf-core-resource-directory is removed after Jim last WGLC We no longer use anchors, just an href in the payload. Check out https://github.com/SanKumar2015/EST-coaps/issues/136  

> 5.2. "Table 2 specifies the mandatory-to-implement or optional implementation of the est-coaps functions." -- How does a client discover which functions are implemented?

Client pre-configuration or optionally resource discovery. We added a reference to the discovery section. 

> 5.3. "Content-Format TBD287 can be used in place of 281" -- It's a bit difficult to see what TBD287 and 281 mean without scrolling all the way down and scrolling back up. Maybe include the table here to make the section easier to read?

I don't think that is necessary as we are stating that TBD287 and 281 "to carry a single certificate instead of a PKCS#7 container in a /crts, /sen, /sren or /skg response ". Also there is a reference to the IANA section in the paragraph above. 

> 5.7. "After a delay of Max-Age, the client SHOULD resend the identical CSR to the server." -- Just for my understanding: Does the submission of a specific CSR always lead to the same output, or can it happen (e.g., if the client submits an identical CSR weeks or months later) that the client would get a different output?

Submitting the same CSR will likely give the client a different output. The reason is that the server cert profile may have changed, but more importantly the issued certificate will have a different lifetime and thus signature value. 

> 5.7. "... or the client abandons for other reasons." -- Does the client need to signal in some way when it wants to abandon?

When the server asks the client to come back in x amount of time, it does not keep state of the client and thus will not care if he returns or not. So, we don't need to require the client to signal that he is giving up. 

> 5.8. "containing a CBOR array with four items Section 5.3" -- Do the two representations (each consisting of two CBOR array items) have to be in a particular order or can they appear in any order?

Any order is fine, since the you can tell what format each representation carries. 

> 6. "In a constrained CoAP environment, endpoints can't always afford to establish a DTLS connection for every EST transaction." -- I'm not aware of any requirement that says CoAP clients must establish a new DTLS connection for every request...

EST mandates using a new truststore after a cacerts request which most usually means a new TLS connection. We can't always require the client to do that in a constrained environment and thus this text. 

> I didn't review the appendices.

Pity, we are sure you could still uncover nits in there. 

Rgs,
Panos

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Klaus Hartke
Sent: Tuesday, February 12, 2019 12:38 PM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est

Jim Schaad wrote:
> it should be sent to the IESG for publication.  We are therefore going 
> to have a Working Group Last Call on this document.  WGLC will until 
> 29th of this month.  Please review the document and send comments both 

I've performed a quick review of draft-ietf-ace-coap-est-08. Sorry for being late to the party.

2. "Therefore, this specification utilizes DTLS [RFC6347], CoAP [RFC7252] and UDP instead of TLS [RFC8446], HTTP [RFC7230] and TCP."
-- Is there a technical reason why EST could not be done over CoAP over TCP, TLS, WebSockets, or SMS?

I understand that it was fashionable at some point to fork a protocol like HTTP, layer some stuff on top of it and call it a new protocol.
However, I would strongly recommend that EST-coaps is presented as an application that is strictly layered on top of CoAP and doesn't define its own custom protocol stack.

4. -- Is this section about the generated certificates or the DTLS connection between the client and the server? If the latter, this section is weird, because RFC 7252 already does define MTI cipher suites and extensions, and I see no reason why an application layered on top of CoAP needs to restate all of that.

4. "The authentication of the EST-coaps client MUST be with a client certificate in the DTLS handshake." -- Why? Why can't a client communicate with a server using any other secure mechanism with client authentication? Or is this just the MTI mechansim?

5.1. The use of the well-known path "/.well-known/est" seems to follow the letter of BCP 190 but not the spirit. I don't see any reason why a well-known path is needed here. In fact, as the section emphasizes, short paths are important and an implementation will there likely want to do the "/.well-known/core"-based discovery of URIs. I would recommend that the entire use of "/.well-known/est" is dropped.

5.1. "Arbitrary Labels are usually defined and used by EST CAs in order to route client requests to the appropriate certificate profile." -- I assume that a client needs to construct URIs from the well-known path "/.well-known/est", the Arbitrary Label and one of the suffixes. How does a client determine which Arbitrary Label to use?

5.1. "The EST-coaps server URIs, obtained through discovery of the EST-coaps root resource(s) as shown below, are of the form:" -- If a client discovers the URIs from "/.well-known/core" (annotated with "ace.est.crts", "ace.est.sen", etc.), is this table 1 still needed? If not, I would recommend that only the 'rt'  values are standardized ("ace.est.crts", "ace.est.sen", etc.) and all paths are left to the implementation, in accordance with BCP 190.

5.1. "Clients and servers MUST support the short resource URIs. The corresponding longer URIs from [RFC7030] MAY be supported." -- Does this provide any benefit or is it just to annoy implementers? Like, we can have short paths, we can have long paths, we cannot decide, so let's have ALL OF THEM!

5.1. "In the context of CoAP, the presence and location of (path to) the management data are discovered by sending a GET request to "/.well-known/core" including a resource type (RT) parameter with the value "ace.est" -- I understand that EST defines the operations on the resources labeled with annotated with "ace.est.crts", "ace.est.sen", etc. but I don't understand what I can do with a resource that is annotated with "ace.est".

5.1. "The first line of the discovery response above MUST be included.
The five consecutive lines after the first MAY be included." -- When would I include what?

5.1. "The return of the content types allows the client to choose the most appropriate one." -- Does the example actually match what a server returns? E.g., does ct="62 280 284 281 TBD287" mean that a server actually returns a TBD287 representation or would it always be a 62 (multipart) representation that happens to contain a TBD287 representation?

5.1. "Port numbers, not returned in the example, are assumed to be the default numbers 5683 and 5684 for CoAP and CoAPS respectively" -- No need to make any assumptions. This is exactly what RFC 7252 specifies.
Please don't make any normative statements that just repeat (or
contradict) what RFC 7252 says.

5.1. "Discoverable port numbers MAY be returned in the <href> of the payload [I-D.ietf-core-resource-directory]." -- What does this mean?
And what does Resource Directory have to do with EST?

5.1. " The server MUST support the default /.well-known/est server root resource and port 5684." -- As said above, I would drop this entirely.

5.1. "Resource discovery is necessary when the IP address of the server is unknown to the client." -- Assuming that "resource directory" refers to "/.well-known/core"-based discovery of URIs, then this is wrong. If the IP address of a server is not known, then a client cannot retrieve the "/.well-known/core" of that server.

5.2. "Table 2 specifies the mandatory-to-implement or optional implementation of the est-coaps functions." -- How does a client discover which functions are implemented?

5.3. "Content-Format TBD287 can be used in place of 281" -- It's a bit difficult to see what TBD287 and 281 mean without scrolling all the way down and scrolling back up. Maybe include the table here to make the section easier to read?

5.3. "If an Accept Option is not included in the request, the client is not expressing any preference and the server SHOULD choose format 281.  If the preferred Content-Format cannot be returned, the server MUST send a 4.06 (Not Acceptable) response, unless another error code takes precedence for the response [RFC7252]." -- Please don't make any normative statements that repeat (or contradict) what RFC 7252 says.

5.3. "The collection is encoded as a CBOR array [RFC7049] with an even number of elements. ..." -- This is already described in [I-D.ietf-core-multipart-ct]. Is there any reason why the text needs to be duplicated?

5.4. "All EST-coaps messages expect a response from the server, thus the client MUST send the requests over confirmable CON CoAP messages."
-- The use of confirmable messages for requests is completely unrelated to whether a response is expected or not. Also, it is entirely inappropriate for an application layered on top of CoAP to mandate the message type.

5.4. "The Ver, TKL, Token, and Message ID values of the CoAP header are not affected by EST." -- And it would be entirely inappropriate if they were. So I'm not sure what to do with this information.

5.4. "The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content-Format, Accept and Location-Path." -- Of course, a server must be prepared to receive requests that include other kinds of options (such as "ETag" or "If-Match") and handle these in accordance to RFC 7252.

5.4. "The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content-Format, Accept and Location-Path." -- The Block options seem to be missing.

5.4. "The Uri-Host and Uri-Port Options are optional." -- No, these options are not optional. They just can be encoded very efficiently (in 0 bytes) if they happen to have their default value.

5.4. "They are usually omitted as the DTLS destination and port are sufficient." -- No. The default values of the options are the IP destination address and UDP port, respectively (in CoAP-over-UDP).

5.4. "Alternatively, if a UDP port to a server is blocked, someone could send the DTLS packets to a known open port on the server and use the Uri-Port to convey the intended port he is attempting to reach."
-- Where is that coming from? Sounds extremely weird.

5.5. "Response code HTTP 202 Retry-After that existed in EST" -- HTTP doesn't have response codes. And there is no status code named "Retry-After" in HTTP.

5.5. "Moreover, if the Content-Format requested in the client Accept Option, is not supported the server MUST return a 4.06 (Not Acceptable), unless another error code takes precedence for the response." -- Please don't make any normative statements that repeat (or contradict) what RFC 7252 says.

5.7. "In particular, a slow server can respond to an EST-coaps enrollment request with an empty ACK with code 0.00, before sending the certificate to the server after a short delay." -- ...before sending the certificate to the *client*?

5.7. "After a delay of Max-Age, the client SHOULD resend the identical CSR to the server." -- Just for my understanding: Does the submission of a specific CSR always lead to the same output, or can it happen (e.g., if the client submits an identical CSR weeks or months later) that the client would get a different output?

5.7. "... or the client abandons for other reasons." -- Does the client need to signal in some way when it wants to abandon?

5.8. "containing a CBOR array with four items Section 5.3" -- Missing word between 'items' and 'Section'

5.8. "containing a CBOR array with four items Section 5.3" -- Do the two representations (each consisting of two CBOR array items) have to be in a particular order or can they appear in any order?

6. "DTLS Transport Protocol" -- This section seems to have the same topic as section 4. Merge section 4 into section 6?

6. "In a constrained CoAP environment, endpoints can't always afford to establish a DTLS connection for every EST transaction." -- I'm not aware of any requirement that says CoAP clients must establish a new DTLS connection for every request...

6. "To alleviate this situation, an EST-coaps DTLS connection MAY remain open for sequential EST transactions." -- An application layered on top of CoAP shouldn't mandate a particular way in which DTLS is used.

8. "Parameters" -- An application layered on top of CoAP shouldn't mandate CoAP congestion control parameters.

10.2. "This EST resource is used to query and return the supported EST resources of a CoAP server." -- Is there any specification for how to query and return the supported EST resources?

Klaus

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 24 Feb 2019 18:07:55 -0600

> The issue is that EST mandates HTTP Basic or Digest Auth and/or client cert auth. HTTP Auth is not defined for COAP application as far as we know. So, for EST-coaps, the only viable authentication…

I think there is enough flexibility in our specifying a "new transport for
EST" that we do not need to be strictly bound to the EST-mandated
authentication mechanisms.  That said, I'm not sure I have any other
options handy than mutual cert auth...

> Any order is fine, since the you can tell what format each representation carries. 

This sort of detail is good to have stated clearly in the document.

-Ben

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Mon, 25 Feb 2019 04:02:37 +0000

Thanks Ben.

I addressed your content-format order comment in the next iteration of the draft by saying 

>   The two representations (each consisting of two CBOR array items) do 
>   not have to be in a particular order since each representation is 
>   preceeded by its Content-Format ID.

Panos

-----Original Message-----
From: Benjamin Kaduk <[email-masked]> 
Sent: Sunday, February 24, 2019 7:08 PM
To: Panos Kampanakis (pkampana) <[email-masked]>
Cc: Klaus Hartke <[email-masked]>; Jim Schaad <[email-masked]>; [email-masked]
Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est

On Fri, Feb 22, 2019 at 09:00:05PM +0000, Panos Kampanakis (pkampana) wrote:
> All your issues identified are tracked here 
> https://github.com/SanKumar2015/EST-coaps/issues?utf8=%E2%9C%93&q=is%3
> Aissue+%22Klaus+WGLC%22 . We tried to address all of them. The fixes 
> we are putting in are spelled out in the github issues themselves. The 
> actual latest version of the draft is 
> https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-c
> oap-est.txt
> 

I think there is enough flexibility in our specifying a "new transport for EST" that we do not need to be strictly bound to the EST-mandated authentication mechanisms.  That said, I'm not sure I have any other options handy than mutual cert auth...

> We needed a way to be able tell the client that the resource is hosted 
> on another port but the reference to  I-D.ietf-core-resource-directory 
> is removed after Jim last WGLC We no longer use anchors, just an href 
> in the payload. Check out 
> https://github.com/SanKumar2015/EST-coaps/issues/136
> 

-Ben

> > it should be sent to the IESG for publication.  We are therefore 
> > going to have a Working Group Last Call on this document.  WGLC will 
> > until 29th of this month.  Please review the document and send 
> > comments both positive and negative to the list about its state.
>

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 27 Feb 2019 17:39:17 +0100

Hi Panos,

thanks for addressing all issues so thoroughly. I've performed another
quick review of draft-ietf-ace-coap-est-09.

5.1. The discovery looks much better now! I think you had 5 or 6 ways
for a client to construct or discover the URIs of an EST deployment.
Now it seems there are only two:

Either (A) the client is configured out-of-band with host name/IP
address, port, and optionally an ArbitraryLabel and constructs a URI
of the form coaps://{hostname]:{port}/.well-known/est/{optionally an
ArbitraryLabel}/{one of the suffixes}.

Or (B) the client is configured out-of-band with host name/IP address
and port, constructs a URI of the form
coaps://{hostname}:{port}/.well-known/core, performs a look up on that
URI, and looks for a link in the response with a resource type of the
form "ace.est.{one of the suffixes}".

But can't the client just be configured out-of-band with the URIs directly?

5.1 "The ArbitraryLabel path-segment, if used, SHOULD be of the
shortest length possible" -- So if someone decides to use an
ArbitraryLabel path-segment consisting of more than 0 characters
(which is the shortest length possible), then it's a protocol
violation? This seems to be a matter of implementation quality to me,
not a requirement for interoperability.

5.1 "(Sections 3.1 and 3.2.2 of [RFC7030]." -- Missing )

5.1 "The EST-coaps server URIs, obtained through discovery of the
EST-coaps root resource(s) as shown below, are of the form:" -- There
is no longer a 'root resource' if a client discovers the full paths.
For example, implementers are free to send the following
/.well-known/core if they want:

   </the/quick/>;rt="ace.est.crts",
   </brown>;rt="ace.est.sen",
   </fox/jumps/over>;rt="ace.est.sren",
   </the/>;rt="ace.est.att",
   </lazy/dog?281>;rt="ace.est.skg",
   </lazy/dog?287>;rt="ace.est.skc"

5.1 "The first three lines of the discovery response above MUST be
returned if the server supports resource discovery." -- ...if it
supports EST? I mean, if a server has a /.well-known/core resource and
implements a draft, is there a reason why it wouldn't include the EST
resources in the /.well-known/core representation? If it doesn't want
to offer two sets of paths, it can simply return this:

   </.well-known/est/crts>;rt="ace.est.crts",
   </.well-known/est/sen>;rt="ace.est.sen",
   </.well-known/est/sren>;rt="ace.est.sren",
   </.well-known/est/att>;rt="ace.est.att",
   </.well-known/est/skg>;rt="ace.est.skg",
   </.well-known/est/skc>;rt="ace.est.skc"

5.1 "The Content-Formats in the response allow the client to request
one that is supported by the server." -- Maybe state explicitly that
these are the values accepted by the server in the Accept option?

5.1 "Discoverable port numbers can be returned in the response
payload." -- Now I'm wondering if that's actually permitted by RFC
6690...

5.1 " The client SHOULD use resource discovery when /.well-known/est
fails" -- But if /.well-known/est fails, then the server clearly
doesn't support EST because of "The server MUST support the default
/.well-known/est root resource.", right?

5.1 "It is up to the implementation to choose its root resource;" --
As above, there is no root resource.

5.4 "All EST-coaps request messages expect an acknowledgement (with a
response payload); EST-coaps requests are confirmable CON CoAP
messages." -- This seems to be a matter of implementation quality and
should not be a requirement for interoperability. I suggest to remove
this.

7. "Parameters" -- This section should be a non-normative
implementation note or removed altogether.

A. "These examples assume a short root resource path of "/est"." -- As
above, there is no root resource. Maybe the very first example in this
section should be a look up of /.well-known/core for the URIs used in
the following subsections?

A.1 "Option Length = 0x9 Option Value = est-coaps.example.org" -- The
value of 0x9 does not match the length of "est-coaps.example.org".
Also in other examples and for other options.

A.1. "The Uri-Host and Uri-Port Options can be omitted" -- But they
aren't in this example. Since it's not important for the example,
maybe just remove Uri-Host and Uri-Port from the example and also this
paragraph?

A.2 "POST [2001:db8::2:1]:61616/est/sen" -- We don't have a standard
format for CoAP examples, but this line uses a different format than
section A.1. It might be good to make this consistent.

Klaus