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.
> 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
