Subject: [Ace] ace-coap-est: unclear definition of /.well-known/est URI

From: Esko Dijk <[email-masked]>
Date: Wed, 12 Sep 2018 15:10:18 +0000

Dear all/authors of ace-coap-est,

Section 5 of ace-coap-est-05 indicates URI discovery is possible to find the EST functions entry point URI. Also a well-known URI is defined:

coaps://www.example.com/.well-known/est/ArbitraryLabel/<short-est>.

This URI seems more complicated than needed? What if we simply define an always-available well-known URI, usable without any discovery:

coaps://www.example.com/.well-known/est/<short-est>

This re-uses the well-known EST namespace which is exactly defined to do EST functions. So using the short-est names within this namespace should be fine.
It is important that a 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

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 12 Sep 2018 15:31:23 +0000

Hi Esko,

Thanks for the comment.

Certificate authorities use the ArbitraryLabel in order to direct the CSR request and issue certificates based on a certain policy / cert profile. For example, if you are ClientX you get label ClientX198282 and when you hit the CA HTTP URI .well-known/est/ ClientX198282/sen the CA knows to use the policy for ClientX in order to issue a certificate. Of course, someone that has deployed an on-prem CA that has the same cert profile for all endpoints will not need an arbitrary label and the default EST namespace is enough.

So, even though coaps://www.example..com/.well-known/est/<short-est> would work for many cases, we needed to keep the coaps://www.example..com/.well-known/est/ArbitraryLabel/<short-est> as well for cases where the client is getting a cert from a CA that serves more than on cert profiles. We may need to specify that the labl should be as short as possible, even though it is kind of self-explanatory.

I hope it makes sense.

Panos

From: Ace [mailto:[email-masked]] On Behalf Of Esko Dijk
Sent: Wednesday, September 12, 2018 11:10 AM
To: [email-masked]
Subject: [Ace] ace-coap-est: unclear definition of /.well-known/est URI

coaps://www.example..com/.well-known/est/ArbitraryLabel/<short-est>.

coaps://www.example..com/.well-known/est/<short-est>

best regards
Esko Dijk

---

From: Peter van der Stok <[email-masked]>
Date: Thu, 13 Sep 2018 09:16:26 +0200

Hi esko,

we can add a reference to sections 3.1 and 3.2.2. of RFC7030

Peter
Panos Kampanakis (pkampana) schreef op 2018-09-12 17:31:

> Thanks for the comment.. 
> FROM: Ace [mailto:[email-masked]] ON BEHALF OF Esko Dijk
> SENT: Wednesday, September 12, 2018 11:10 AM
> TO: [email-masked]
> SUBJECT: [Ace] ace-coap-est: unclear definition of /.well-known/est URI 
> 
> Section 5 of ace-coap-est-05 indicates URI discovery is possible to find the EST functions entry point URI.. Also a well-known URI is defined: 
> 
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Esko Dijk <[email-masked]>
Date: Sat, 15 Sep 2018 14:30:09 +0000

Hello Panos,

Thanks - it's clear now that the "ArbitraryLabel" needs to be supported for this use case. The unclarity in the current text comes from the fact that the default /.well-known/est/<short-est> is missing ; which should be supported also as in RFC 7030. Also the usage of the discoverable root URI is missing here.

So we could update the text in Section 5 as follows:

------
The individual EST-coaps well-known server URIs differ from the EST URI by
replacing the scheme https by coaps and by specifying shorter
resource path names:

   coaps://www.example.com/.well-known/est/<short-est>
   coaps://www.example.com/.well-known/est/ArbitraryLabel/<short-est>

The ArbitraryLabel Path-Segment, if used, SHOULD be of the shortest length
possible.

The optional additional EST-coaps server URIs, obtained through discovery of the EST
root resource(s), are of the form:

   coaps://www.example.com/<est-root-resource>/<short-est>
   coaps://www.example.com/<est-root-resource>/ArbitraryLabel/<short-est>

------

The suggestion by Peter to add references to the corresponding EST RFC 7030 sections is also good.

Regards
Esko

From: Panos Kampanakis (pkampana) <[email-masked]> 
Sent: Wednesday, September 12, 2018 17:31
To: Esko Dijk <[email-masked]>; [email-masked]
Subject: RE: ace-coap-est: unclear definition of /.well-known/est URI

Hi Esko,

Thanks for the comment. 

I hope it makes sense.

Panos

To: mailto:[email-masked]

best regards
Esko Dijk

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Mon, 17 Sep 2018 17:11:47 +0000

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:[email-masked]] 
Sent: Saturday, September 15, 2018 10:30 AM
To: Panos Kampanakis (pkampana) <[email-masked]>; [email-masked]
Subject: RE: ace-coap-est: unclear definition of /.well-known/est URI

Hello Panos,

------
The individual EST-coaps well-known server URIs differ from the EST URI by replacing the scheme https by coaps and by specifying shorter resource path names:

The ArbitraryLabel Path-Segment, if used, SHOULD be of the shortest length possible.

The optional additional EST-coaps server URIs, obtained through discovery of the EST root resource(s), are of the form:

------

Regards
Esko

Hi Esko,

Thanks for the comment. 

I hope it makes sense.

Panos

best regards
Esko Dijk

---

From: Esko Dijk <[email-masked]>
Date: Tue, 18 Sep 2018 14:31:29 +0000

Ok, thanks.

To be fully complete the URIs that can be discovered should also include a port number, as they could be hosted at 5684 or any available UDP port - other than 5683.

   coaps://www.example.com:<port>/<est-root-resource>/<short-est>
   coaps://www.example.com:<port>/<est-root-resource>/ArbitraryLabel/<short-est>

Esko

-----Original Message-----
From: Panos Kampanakis (pkampana) <[email-masked]> 
Sent: Monday, September 17, 2018 19:12
To: Esko Dijk <[email-masked]>; [email-masked]
Subject: RE: ace-coap-est: unclear definition of /.well-known/est URI

Hi Esko,

-----Original Message-----
From: Esko Dijk [mailto:[email-masked]] 
Sent: Saturday, September 15, 2018 10:30 AM
To: Panos Kampanakis (pkampana) <[email-masked]>; [email-masked]
Subject: RE: ace-coap-est: unclear definition of /.well-known/est URI

Hello Panos,

------

------

Regards
Esko

Hi Esko,

Thanks for the comment. 

I hope it makes sense.

Panos

best regards
Esko Dijk

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Sep 2018 10:51:09 -0400

Esko Dijk <[email-masked]> wrote:
    > To be fully complete the URIs that can be discovered should also
    > include a port number, as they could be hosted at 5684 or any available
    > UDP port - other than 5683.

    >    coaps://www.example.com:<port>/<est-root-resource>/ArbitraryLabel/<short-est>

I didn't think that CoAP resource discovery supports port numbers, does it?

There are some issues with this, specifically because it interacts poorly
with the join proxy mechanism.  (The proxy always forwards to a single port,
and only listens on a single port)

I supppose that's okay, for that usage can be banned for the zero-touch join
mechanisms that use a join proxy.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Peter van der Stok <[email-masked]>
Date: Thu, 20 Sep 2018 16:56:29 +0200

Michael Richardson schreef op 2018-09-20 16:51:

> It does; at least for the 3rd party registration, but also examples in the RD show return of port

---

From: Esko Dijk <[email-masked]>
Date: Thu, 20 Sep 2018 15:21:56 +0000

Indeed, and the ace-coap-est examples use port 61616 mostly. The discovery Link Format is quite inefficient when returning results on *different* endpoints. Example:

REQ: GET coap://[2001:db8::2:1]/.well-known/core?rt=ace.est
RES: 2.05 Content
  <coaps://hostcanhavealongname.example.com:61616/est>;rt="ace.est"

Although in above case the server could shorten the response payload by returning its IP address ( <coaps://[2001:db8::2:1]:61616/est>;rt="ace.est"). But still it’s a waste of bytes.
The current example in Section 5 of ace-coap-est is problematic, because discovery is on port 5683 and the hosted EST endpoint is on the secure port 5684. So the following won’t work according to RFC 7252 / RFC 6690:

REQ: GET coap://[2001:db8::2:1]/.well-known/core?rt=ace.est
RES: 2.05 Content
  </est>;rt="ace.est"

Because strictly speaking this tells the client that /est is hosted on port 5683 (no statement about 5684 hosting!)
I see this as a design flaw in CoAP discovery; we would like to be able to use the above short syntax of course.

@Michael:
Since the EST resource is always present on the fixed port 5684 on URI /.well-known/est - if a fixed port is needed e.g. for a join proxy, use 5684 and the well-known URI. No discovery needed.

Esko

From: Peter van der Stok <[email-masked]>
Sent: Thursday, September 20, 2018 16:56
To: Michael Richardson <[email-masked]>
Cc: Esko Dijk <[email-masked]>; Panos Kampanakis (pkampana) <[email-masked]>; [email-masked]
Subject: Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Sep 2018 15:47:00 -0400

Esko Dijk <[email-masked]> wrote:
    > Indeed, and the ace-coap-est examples use port 61616 mostly. The
    > discovery Link Format is quite inefficient when returning results on
    > *different* endpoints. Example:

    > <coaps://hostcanhavealongname.example.com:61616/est>;rt="ace.est"

I understand.

    > Although in above case the server could shorten the response payload by
    > returning its IP address ( <coaps://
    > [2001:db8::2:1]:61616/est>;rt="ace.est"). But still it’s a waste of
    > bytes.

It could have multiple addresses!!!
I've seen it just return </est>, but I guess if you want to return the
port number, you have to return the hostname... <:61616/est> won't do?

    > The current example in Section 5 of ace-coap-est is problematic,
    > because discovery is on port 5683 and the hosted EST endpoint is on the
    > secure port 5684. So the following won’t work according to RFC 7252 /

So I've assumed that discovery happens on 5684, under DTLS.
You are suggesting that we need to run an unencrypted CoAP to offer the
discovery option as well.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Sep 2018 16:34:37 -0400

> Since the EST resource is always present on the fixed port 5684 on URI
    > /.well-known/est - if a fixed port is needed e.g. for a join proxy, use
    > 5684 and the well-known URI. No discovery needed.

I've asked if discovery is always required, permitted, or encouraged.

I.e. - can the client avoid the round trip to do the discovery?
     - does the server have to provide the discovery?
       -- if not, what does a client do that performs the discovery and fails?

I've been told it was required.

---

From: Esko Dijk <[email-masked]>
Date: Fri, 21 Sep 2018 08:08:32 +0000

> port number, you have to return the hostname... <:61616/est> won't do? 

The closest thing valid according to the ABNF definitions would be
<coaps://:61616/est>

But unfortunately CoAP by its RFC 7252 URI definition forbids using an empty host (reg-name) in a CoAP URI.

> discovery option as well. 

Ok, discovery can happen on port 5684 - in general a CoAP server MAY support discovery on 5684 and MUST support it on 5683 if discovery is offered.
For our purposes, ace-coap-est could require that an EST server MUST offer discovery on port 5684. And we avoid any long-URI issues in the return payload.

Esko

---

From: Esko Dijk <[email-masked]>
Date: Fri, 21 Sep 2018 08:24:36 +0000

> 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 support it also in coaps-est and no additional squatting takes place. Besides support for the well-known URI location, discovery by a client is permitted to find "ace.est" type resources at other places e.g. to get shorter URIs or to get 6lowpan-compressible port numbers, or both.

> I've been told it was required.

- So it can't be required for the client, is my opinion. 
- The server must support it (being a good CoAP-citizen) in some way as in the previous email.
- If it fails, the client might try another time using the /.well-known/est resource, or retry the discovery later on. (There could be various implementation-specific tactics here. Maybe the IP address of the EST server was configured wrongly; and the process that lead to this IP address can be redone by the client.)

Esko

---

From: Peter van der Stok <[email-masked]>
Date: Mon, 24 Sep 2018 09:39:27 +0200

Sorry folks,

But you confuse me.
discovery is about /.well-known/core.
I don't understand where /.well-known/est comes in for discovery.

Peter.

---

From: Peter van der Stok <[email-masked]>
Date: Mon, 24 Sep 2018 10:11:34 +0200

Hi,

What do I read?
when you do GET coap://example.com/.well-known/core
The discovery is on port 5683.
When you do GET coaps://example.com/.well-known/core
the discovery port is 5684.

I agree that we did not assign a port to coaps://example.com/est for
that matter,
and as such the example is incorrect. Will we make the port
discoverable?

RFC 7030 does not ask a port number from IANA.
And a search through IANA port numbers on "est" does not yield anything.

Any suggestions? or improve my knowledge.

Peter

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Mon, 24 Sep 2018 14:24:33 +0000

EST by default runs on port 443 over TLS. It does not have any special port. Discovery is not defined in 7030. It is defined in BRSKI. And it based on GRASP or mDNS service discovery.

I think it is not necessary to define a default port. The default COAPS UDP 5684 suffices. Now if a server wants to advertise a different port then we would need the full URI with the port.

From: Peter van der Stok [mailto:[email-masked]]
Sent: Monday, September 24, 2018 4:12 AM
To: Esko Dijk <[email-masked]>
Cc: Michael Richardson <[email-masked]>; Panos Kampanakis (pkampana) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI

Hi,

What do I read?

I agree that we did not assign a port to coaps://example.com/est for that matter,
and as such the example is incorrect. Will we make the port discoverable?

Peter

Esko

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Sep 2018 12:27:20 -0400

Peter van der Stok <[email-masked]> wrote:
    > What do I read?  when you do GET coap://example.com/.well-known/core
    > The discovery is on port 5683.  When you do GET
    > coaps://example.com/.well-known/core the discovery port is 5684.

yes, the question is, when you ask:

coap://example.com/.well-known/core?rt=ace.est

do you expect to get back a pointer to:

   coaps://example.com/est

    > RFC 7030 does not ask a port number from IANA.  And a search through
    > IANA port numbers on "est" does not yield anything.

It does not.
a) it doesn't do discovery, but just uses /.well-known directly.
b) it assumes https://

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Jim Schaad <[email-masked]>
Date: Mon, 24 Sep 2018 10:21:58 -0700

> From: Ace <[email-masked]> On Behalf Of Michael Richardson
> Sent: Monday, September 24, 2018 9:27 AM
> To: [email-masked]

Is there any reason to assume that you need a different port from the
default pair of coap ports?  Knowing what the protocol and host name will
point it to the correct location and you have the URI path to go to the
correct resource on that server.  

Jim