Hi Hendrik, On Tue, Feb 15, 2022 at 07:42:31AM +0000, Brockhaus, Hendrik wrote: > Ben > > Thank you for your review and your comment on CMP Updates. > I will just comment on the usage of "cmp" well-known URI and leave the other > comments to the authors of draft-ietf-ace-cmpv2-coap-transport-04.
Understood. I am under a bit of a time crunch preparing for tomorrow's IESG telechat, but the short answer is: RFC 7030 is not a good example, but for draft-ietf-ace-coap-est it is more important to be consistent with RFC 7030 EST than to use regular best practices for well-known URIs. A brief look into the history of RFC 7030 reveals that several reviewers took objection to the usage of "arbitrary labels" under /.well-known/est in question here, including a DISCUSS ballot from Stephen Farrell. Unfortunately, (in my assessment) it seems that that position was converted to a COMMENT prematurely, as only the question of "how would this even work at all" was resolved, and the question of "why does this need to be well-known" was not. In particular, if you have out-of-band between client and server about what "arbitrary label" to use, then there is by assumption a channel that could be used to coordinate what URI to use, so the server could just assign a regular URI out of the portion of the URI namespace that is wholly under its control (i.e., just the toplevel /arbitraryLabel1 would work) in a manner that is compliant with BCP 190. Given this configuration channel there is no need to use a well-known URI at all, and re-delegating a portion of the well-known namespace back to the hosting server seems to provide little or no value, at the cost of making future protocol evolution much more difficult. That said, if there is some use case (perhaps a third-party coordinator that does not control the server's URI namespace) for remaining under well-known, it is safe to specify in the RFC that (e.g.) /.well-known/cmp/local is available for the server to use with arbitrary labels underneath it, and ideally what the semantics of those labels are. My strongest concern is with the intermingling of arbitrary labels at the toplevel /.well-known/cmp/ with potential future protocol extensions. We need to retain a well-known namespace fully under the control of the protocol and with no risk of conflict to server-operator-assigned names. -Ben > > Von: Ace <ace-boun...@ietf.org> Im Auftrag von Benjamin Kaduk > > Gesendet: Montag, 14. Februar 2022 20:22 > > > > Hi all, > > > > Jumping right in... > > > > > > I guess this is probably more of a comment on draft-ietf-lamps-cmp-updates, > > but since we are duplicating some of its content I will still call it out > > as a as a > > serious concern. My concern relates to the usage of the "cmp" > > well-known URI -- we hvae some text in §2.1 that effectively says that a > > local > > site can just put more path segments under that path at its own discretion, > > and there's not even any restrictions made on the structucture of the > > additional path segments -- the next segment could be an operational label > > or a profile label, in the examples given. This seems entirely at odds with > > the purpose of well-known URIs as per RFC 8615 -- they are to be URIs whose > > semantics are entirely specified by a protocol specification and are *not* > > subject to local operator control. While it is possible for a > > specification to > > introduce additional structure under its registered well-known path, it's > > expected that the semantics of those subtrees are still specified by the > > protocol, and any extensions are to be managed by a (sub-)registry. See, > > for > > example, §8.3.2 of RFC 8995, that establishes a sub-registry for the path > > components under /.well-known/brski . > > > > Any changes here will of course need to be synchronized with draft-ietf- > > lamps-cmp-updates, but I don't think this draft can go forward in its > > current > > form. > > > When writing the sections on http and coap transfer in Lightweight CMP > Profile and CMP Updates I took RFC 7030 as example. > RFC 7030 §3.2.2 states > An EST server MAY provide service for multiple CAs as indicated by an > OPTIONAL additional path segment between the registered application > name and the operation path. To avoid conflict, the CA label MUST > NOT be the same as any defined operation path segment. The EST > server MUST provide services regardless of whether the additional > path segment is present. The following are three example valid URIs: > > 1. https://www.example.com/.well-known/est/cacerts > > 2. https://www.example.com/.well-known/est/arbitraryLabel1/cacerts > > 3. https://www.example.com/.well-known/est/arbitraryLabel2/cacerts > > Also draft-ietf-ace-coap-est §5.1 makes use of arbitraryLables > For both types of installations, saving header space is important and > short EST-coaps URIs are specified in this document. These URIs are > shorter than the ones in [RFC7030]. Two example EST-coaps resource > path names are: > > coaps://example.com:<port>/.well-known/est/<short-est> > coaps://example.com:<port>/.well-known/est/ArbitraryLabel/<short-est> > > CMP Updates §3.3 makes use of these examples and adapts them to CMP needs > renaming arbitraryLable to profileLable. The operationLable is specified in > Lightweight CMP Profile. > The CMP client needs to be configured with sufficient information to > form the CMP server URI. This is at least the authority portion of > the URI, e.g., 'www.example.com:80', or the full operation path > segment of the PKI management entity. Additionally, OPTIONAL path > segments MAY be added after the registered application name as part > of the full operation path to provide further distinction. A path > segment could for example support the differentiation of specific > CAs, certificate profiles, or PKI management operations. A valid > full CMP path can look like this: > > http://www.example.com/.well-known/cmp > http://www.example.com/.well-known/cmp/operationLabel > http://www.example.com/.well-known/cmp/profileLabel > http://www.example.com/.well-known/cmp/profileLabel/operationLabel > > The operational labels for usage with http are further specified in > Lightweight CMP Profile §6.1 (and for coap see §6.2). > PKI management operations SHOULD use URI paths consisting of '/.well- > known/cmp/' followed by an operation label depending on the type of > PKI management operation. > > +============================+=====================+=========+ > | PKI management operation | operation label | Details | > +============================+=====================+=========+ > | Enroll client to new PKI | /initialization | Section | > | | | 4.1.1 | > +----------------------------+---------------------+---------+ > | Enroll client to existing | /certification | Section | > | PKI | | 4.1.2 | > +----------------------------+---------------------+---------+ > | Update client certificate | /keyupdate | Section | > | | | 4.1.3 | > +----------------------------+---------------------+---------+ > | Enroll client using | /p10 | Section | > | PKCS#10 | | 4.1.4 | > +----------------------------+---------------------+---------+ > | Revoke client certificate | /revocation | Section | > | | | 4.2 | > +----------------------------+---------------------+---------+ > | Get CA certificates | /getcacerts | Section | > | | | 4.3.1 | > +----------------------------+---------------------+---------+ > | Get root CA certificate | /getrootupdate | Section | > | update | | 4.3.2 | > +----------------------------+---------------------+---------+ > | Get certificate request | /getcertreqtemplate | Section | > | template | | 4.3.1 | > +----------------------------+---------------------+---------+ > | Get CRL updates | /getcrls | Section | > | | | 4.3.4 | > +----------------------------+---------------------+---------+ > | Batching messages | /nested | Section | > | | | 5.2.2.2 | > | Note: This path element is | | | > | applicable only between | | | > | PKI management entities. | | | > +----------------------------+---------------------+---------+ > > Table 1: HTTP endpoints > > May be I missed something. Could you explain where you see the difference > between the usage of /.well-known/ in RFC 7030 and in CMP Updates and > Lightweight CMP Profile or why this approach is not appropriate anymore. > > Hendrik _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
