Re: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt

["Panos Kampanakis (pkampana)" <[e-mail]>]

Thanks Esko. 

Addressed in https://github.com/SanKumar2015/EST-coaps/blob/84ce0c1d5e768d40e97184214bae404da21bd050/draft-ietf-ace-coap-est.xml Two comments: 

> page 11 bottom requirement: " The client SHOULD use resource discovery when he is unaware of the available  EST-coaps resources." - when an EST server is known, this requirement does not really apply since the server always supports .well-known EST resources.  So I read it as doing an RD discovery or multicast CoAP discovery if the client doesn't known the EST server address.  Hope this is clear enough in the text and intended?

There are optional resources like /att, /skg and /skc that the server does not have to support, so that is what this sentence was referring to. 

> page 11 bottom: " It is up to the implementation to choose its resource paths” -> seems not really the case, because the root resource structure is forced by the specification. It could have been designed as free choice (because it can be discovered anyway) but it is not.

The text says that the server MUST support the default /.well-known/est root resource and it SHOULD support resource discovery for non-default URIs (like /est or /est/ArbitraryLabel) or ports. In the latter case it is up to the server to decide the paths he makes its resources available at. That is what this sentence was referring to. But you are right; I realized that this sentence is redundant 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 <[e-mail]> 
Sent: Monday, May 20, 2019 2:31 AM
To: Panos Kampanakis (pkampana) <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: RE: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt

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 of the EST resources." - this is not true, since only the individual supported resources are returned. The root (e.g. "/est" in the examples) can be deduced from the response but it is never returned as one link format entry.
- page 11 top: the example is only correct for a secure (coaps://) discovery GET request, I think this could be mentioned in text or indicated in the request line.
- page 11 bottom requirement: " The client SHOULD use resource discovery when he is unaware of the available  EST-coaps resources." - when an EST server is known, this requirement does not really apply since the server always supports .well-known EST resources.  So I read it as doing an RD discovery or multicast CoAP discovery if the client doesn't known the EST server address.  Hope this is clear enough in the text and intended?
- page 11 bottom: "he supports" -> "it supports"
- page 11 bottom: " It is up to the implementation to choose its resource paths” -> seems not really the case, because the root resource structure is forced by the specification. It could have been designed as free choice (because it can be discovered anyway) but it is not.

Best regards
Esko

-----Original Message-----
From: Ace <[e-mail]> On Behalf Of Panos Kampanakis (pkampana)
Sent: Friday, May 17, 2019 17:36
To: [e-mail]
Subject: Re: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt

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" pointed out by Esko. 

The diff is here https://tools.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-11.txt 

Thanks,
Panos

-----Original Message-----
From: Ace <[e-mail]> On Behalf Of [e-mail]
Sent: Friday, May 17, 2019 11:31 AM
To: [e-mail]
Cc: [e-mail]
Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF.

        Title           : EST over secure CoAP (EST-coaps)
        Authors         : Peter van der Stok
                          Panos Kampanakis
                          Michael C. Richardson
                          Shahid Raza
	Filename        : draft-ietf-ace-coap-est-11.txt
	Pages           : 48
	Date            : 2019-05-17

Abstract:
   Enrollment over Secure Transport (EST) is used as a certificate
   provisioning protocol over HTTPS.  Low-resource devices often use the
   lightweight Constrained Application Protocol (CoAP) for message
   exchanges.  This document defines how to transport EST payloads over
   secure CoAP (EST-coaps), which allows constrained devices to use
   existing EST functionality for provisioning certificates.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-coap-est-11
https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-11


Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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