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) <pkamp...@cisco.com>; ace@ietf.org Subject: RE: ace-coap-est: unclear definition of /.well-known/est URI 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) <pkamp...@cisco.com> Sent: Wednesday, September 12, 2018 17:31 To: Esko Dijk <esko.d...@iotconsultancy.nl>; ace@ietf.org Subject: RE: ace-coap-est: unclear definition of /.well-known/est URI 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:ace-boun...@ietf.org] On Behalf Of Esko Dijk Sent: Wednesday, September 12, 2018 11:10 AM To: mailto:ace@ietf.org Subject: [Ace] ace-coap-est: unclear definition of /.well-known/est URI 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 _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
