Subject: [Ace] AD review of draft-ietf-ace-cmpv2-coap-transport-04

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 14 Feb 2022 11:22:17 -0800

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.

Abstract

   This document specifies the use of Constrained Application Protocol
   (CoAP) as a transfer mechanism for the Certificate Management
   Protocol (CMP).  purpose of certificate creation and management.

Is the last quoted sentence (fragment) an editing artifact or is there
supposed to be more content there?

   CoAP is an HTTP like client-server protocol used by various
   constrained devices in the IoT space.

nit: hyphenate "HTTP-like"

Section 1

   messages.  The Constrained Application Protocol (CoAP) defined in
   [RFC7252], [RFC7959] and [RFC8323] is a client-server protocol like
   HTTP.  It is designed to be used by constrained devices over

(editorial) I would suggest putting a paragraph break before talking about
CoAP.

Section 2.2

                                  If the port number is not specified in
   the authority, then port 5683 MUST be assumed for the "coap://"
   scheme and port 5684 MUST be assumed for the "coaps://" scheme.

If I'm not mistaken, these ports 5683/5684 are the normal default ports for
coap/coaps, as mandated by RFC 7252.  We don't need to restate that
requirement using normative keywords, as the normative requirement is made
in RFC 7252.  Instead (if anything), we should just provide a statement of
fact, e.g., "the default port for coap: scheme URIs is 5683 and the default
port for coaps: scheme URIs is 5684 [RFC7252]".  But really, we should be
able to expect people to know to find the deafult port for a given URI
scheme.

Section 2.3

   CoAP POST request.  A CMP client SHOULD send CoAP requests marked as
   Confirmable message ([RFC7252] section 2.1).  If the CoAP request is

nit: singular/plural mismatch "message"/"requests".  Since we use the
singular in the next sentence, going to singular here is probably best,
e.g., "SHOULD send each CoAP request marked as a Confirmable message".

   successful then the server MUST return a "2.05 Content" response
   code.  [...]

Perhaps I am reading too much into the analogy between HTTP and CoAP and
thus to the applicability of draft-ietf-httpbis-bcp56bis (currently with the
RFC Editor), but it doesn't seem terribly useful to name a specific response
code here.  The standard CoAP semantics apply, and we could probably just
say that "the paylaod of a successful response contains the DER-encoded
...".

   When transferring CMP PKIMesssage over CoAP the media type
   "application/pkixcmp" MUST be used.

Do we want to say media type or content-format here?

Section 2.4

                           These structures may contain many optional
   and potentially large fields, a CMP message can be much larger than
   the Maximum Transmission Unit (MTU) of the outgoing interface of the
   device.  [...]

nit: comma splice

   MUST be used for the CMP Transactions over CoAP.  If a CoAP-to-HTTP
   proxy is in the path between EEs and CA or EEs and RA then it MUST
   receive the entire body from the client before sending the HTTP
   request to the server.  [...]

It will be interesting to see what the ART and transport reviewers think of
this guidance.  It seems like it is technically possible for the proxy to
use a chunked encoding and stream the message without buffering, and it's
not immediately clear to me that the cost of having to buffer chunks for
reassembly outweights the cost of maintaining an HTTP connection in the
current threat model.

Also, nit: I would suggest using "EE" singular in both instances.

                           This will avoid unnecessary errors in case
   the entire content of the PKIMesssage is not received and the proxy
   opens a connection with the server.

I'm not sure I understand where these errors are such that they would be
"unnecessary".  The client will certainly see an error condition even if not
an error CoAP response, and the proxy will see an error condition of an
incomplete request.  So I guess that would just leave the CA or RA as being
protected from an error condition, but I don't really see why they need to
be protected from them.  Isn't the occasional incomplete request just part
of normal operation on best-effort networks?

Section 2.6

   As there are no request messages specified for these announcement
   messages, an EE MAY use CoAP Observe option [RFC7641] in the Get
   request to the CMP server's URI followed by "/ann" to register itself
   for any Announcements messages.  [...]

This is a pretty awkward sentence construction; I assume because it tries to
allow for the flexibility in use of /.well-known/cmp/ that I complained
about earlier.  Just saying that you can use Observe with a Get request to
the /.well-known/cmp/ann resource is much simpler to state.

                                    If the server supports CMP
   Announcements messages, then it can respond with response code 2.03
   "Valid", otherwise with response code 4.04 "Not Found".  [...]

This reads a lot like we're trying to say that 2.03 and 4.04 are the only
options, which BCP 56 (bis) says is an anti-pattern.

                                                            If for some
   reason server cannot add the client to its list of observers for the

nit: "the server"

   announcements, it can omit the Observe option [RFC7641] in the 2.03
   response to the client.  A client on receiving 2.03 response without

nit: "a 2.03 response"

   Observe option [RFC7641] can try after some time to register again
   for announcements from the CMP server.

nit: "the Observe option"

   Alternatively an EE MAY poll for the potential changes via "PKI

nit: comma after "alternatively"

   Information" request using "PKI General Message" defined in the
   PKIMessage [RFC4210] for various type of changes like CA key update

"PKI General Message" is a "PKIBody" type conveyed within the PKIMessage.
Is it more clear to say something like '''using the "PKI General Message"
choice for the PKIBody of the PKIMessage [RFC4210]'''?

(editorial) I'd also suggest ending the sentence there, and starting a new
sentence to list the common types of changes that would be polled for,
perhaps as "This procedure allows the EE to receive various types of
changes, like ..."

   or to get current CRL [RFC5280] to check revocation or using Support
   messages defined in section 5.4 of Lightweight CMP Profile
   [I-D.ietf-lamps-lightweight-cmp-profile] .  [...]

The Support messages seem to be in §4.3 of the lightweight profile now (not
5.4).

Also (editorial), the list structure here seems hard to follow ("like <A> or
<B> to <X> to <Y> or using <C>".  There are no list separators (e.g.,
commas), and there is not clear parallelism between the structure of each
list item (e.g., the last one is just "using Support messages" but the
lead-in to the list is "various types of changes like" -- "combining those
to "various types of changes like using Support messages" doesn't make a
coherent clause ... so it's unclear if it's supposed to be part of the same
list or not).

   It will also simplify the implementation of CoAP-to-HTTP proxy.

nit: singular/plural mismatch (the singular would need an article, for "a
CoAP-to-HTTP proxy").

Section 3

   Although CMP protocol does not depend upon the underlying transfer
   mechanism for protecting the messages but in cases when an end to end
   secrecy is desired for the CoAP, CoAP over DTLS [I-D.ietf-tls-dtls13]
   SHOULD be used.  [...]

I'm not sure I understand what you mean by "end-to-end secrecy" for CoAP
here -- DTLS is going to terminate at the closest entity that's named at the
CoAP layer, which could include a CoAP or CoAP/HTTP proxy.  Full end-to-end
secrecy between client and origin server would require an object sercurity
mechanism like OSCORE.  DTLS would provide confidentiality protection
against intermediate nodes at the IP layer, but that's only end-to-end in a
certain sense.

Also, nits: "end-to-end" is hyphenated as an adjective, "the CMP protocol",
and s/ but/,/

                    Section 9.1 of [RFC7252] defines how to use DTLS
   [I-D.ietf-tls-dtls13] for securing the CoAP.  Once a DTLS
   [I-D.ietf-tls-dtls13] connection is established it SHOULD be used for
   as long as possible to avoid the frequent overhead of setting up a
   DTLS [I-D.ietf-tls-dtls13] connection for constrained devices.

nit: for DTLS we typically talk about an "association" rather than a
"connection" (though the latest DTLS 1.3 draft does allow "connection" as a
synonym for "association").

Section 4

   In case the proxy is deployed closer to the EEs then it may also
   support service discovery and resource discovery as described in
   section 2.2.  [...]

Why does being closer to the RA or CA obviate the proxy from supporting
service and resource discovery?  Won't there still be a need to expose the
resources to the CoAP network regardless of how close it is to the EEs?

   o  Use separate hostnames for each of the configured servers and then
      use Server Name Indication ( [RFC8446] ) in case of "coaps://"
      scheme for routing CoAP requests.

RFC 6066 is probably a better reference for SNI than RFC 8446.
Also, there still needs to be Uri-Host even when SNI is used, and the proxy
needs to enforce that the two values match, in order to protect against
request-smuggling attacks.

Section 5

Should we say anything about how failing to receive announcement messages in
a timely fashion can cause the EE to miss revocation events (and maybe other
things as well)?  CoAP Observe notes that it is only a "best-effort"
approach and the server could lose state about subscribed clients, which is
probably worth re-emphasizing.

We might also note that the use of DTLS can provide confidentiality
protection for CMP-level metadata (though probably cannot obscure the fact
that CMP is in use).

I would also suggest making a statement about what security properties are
required from a CoAP/HTTP proxy.  Since CMP itself provides end-to-end
protections, I expect these requirements to be fairly weak (i.e., we don't
need to trust the operator of it with any sensitive plaintexts), but it
seems worth stating what considerations may arise.

   The CMP protocol depends upon various mechanisms in the protocol
   itself for making the transactions secure therefore security issues
   of CoAP due to using UDP do not carry over to the CMP layer.  [...]

I think what we're trying to emphasize here is "using UDP without
cryptographic protections for message confidentiality and integrity", since
we go on to talk about how the connectionless nature of UDP remains an
issue.

Also, nit: comma before "therefore".

   In order to to reduce the risks imposed by DoS attacks, the
   implementations SHOULD minimize fragmentation of messages, i.e. avoid
   small packets containing partial CMP PKIMessage data.

Up in §2.4 we said ("MUST"!) to use block-wise transfer to avoid (IP)
fragmentation.  Does this guidance apply to only IP fragmentation as well,
or also to CoAP-layer "fragmentation" (i.e., block-wise transfer)?  The
latter seems nearly impossible to achieve, given that the X.509 structures
used by CMP are unchanged by this transport and are likely to be too large
for a single datagram.

   A CoAP-to-HTTP proxy can also protect the PKI entities from various
   attacks by enforcing basic checks and validating messages before
   sending them to PKI entities.  [...]

What's the motivation behind just using a vague phrase "various attacks"
instead of listing more details of known attacks (while still stating that
the explicit listing is incomplete)?

Also, we should note that putting the proxy in this position causes the
proxy itself to be at risk of attack.  (In particular, our requirement for
CoAP-to-HTTP proxies to buffer CoAP requests before initiating the outbound
HTTP request subjects them to a resource-exhaustion attack.)

Section 8.1

   [RFC6712]  Kause, T. and M. Peylo, "Internet X.509 Public Key

The RFC Editor will surely fix this, but it's quite unusual to mix "Last,
FI" and "FI. Last" format for names in the same reference.

Section 8.2

I think DTLS 1.3 needs to be a normative reference based on how we give
SHOULD-level guidance to use it.  (I don't think we're specifically tied to
1.3, though, and if for some reason DTLS 1.3 still hasn't been published by
the time this document is ready, we could swap it out for DTLS 1.2.)

Section 8.3

The two URIs [1] and [2] seem to be identical; are they both needed?

Thanks,

Ben

---

From: Mohit Sahni <[email-masked]>
Date: Mon, 14 Feb 2022 12:25:28 -0800

Hi Ben,
Many thanks for your comments. I will review them and make the changes
accordingly.

Regards,
Mohit

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Tue, 15 Feb 2022 07:42:31 +0000

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 <[email-masked]> Im Auftrag von Benjamin Kaduk
> Gesendet: Montag, 14. Februar 2022 20:22
> 
> Hi all,
> 
> Jumping right in...
> 
> 
> 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

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 16 Feb 2022 15:29:19 -0800

Hi Hendrik,

> 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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Feb 2022 12:16:22 -0500

Benjamin Kaduk <[email-masked]> wrote:
    > 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.

Yes, as a deep reader of RFC7030, these labels always seemed like a solution
looking for a problem.

    > 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

I always assumed that the arbitrary label was something that the manufacturer
provisioned.
A device that needed multiple certificates for, "email", "https" and "xmpp"
would know that, it would use that kind of thing there.   THe different
labels would be patched through a front-end to different CAs in the backend.
But that this was entirely a local thing.

I actually always thought that /.well-known was excessive for EST, period.
I can't imagine a situation where an EST Registrar would do anything else.
There is a big operational difference between EST vs securitytxt, which might be on any server.

But, what mattered is that we pick a common place to put the EST stuff, and
the established part of the dance floor that the IETF has marked off is
/.well-known, so EST is there.
It makes sense to put CMP there too.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 21 Feb 2022 11:48:51 +0000

Ben

Many thanks for your explanation. I had some exchange with the co-authors and others.
Please see my comments and proposal below.

I added LAMPS to the email, as this discussion addressed comments on CMP Updates.

> Von: Benjamin Kaduk <[email-masked]>
> Gesendet: Donnerstag, 17. Februar 2022 00:29
> 
> Hi Hendrik,
> 
> > 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.

You are absolutely right that draft-ietf-ace-coap-est needs to be closer to EST that CMP. But finally, EST and CMP have similar requirements regarding targeting operations to a specific CA to enroll a specific certificate type. There is a good chance that both protocols will be offered on the same RA or CA system. Therefore, I thought it would be a good idea to structure the URIs similarly.

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

During the adoption call of CMP Updates and Lightweight CMP Profile two years ago, there was also a discussion on the URIs. As I remember the discussion, issues could be resolved by offering this arbitrary label.
The reason is simple, a CA or RA will offer certificate management functionality for more than one CA or for more than one certificate profile or type. EST has no means to express this in the content of the message. CMP could express this information in the CMP message header, but many implementers of CMP see the advantage to express this also as part of the URI not to dig into the ASN.1 to get this general information.

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

The arbitraryLabel could be a generic indication of the type of certificate to be managed. This can be device or solution specific and can be even hardcoded on the device. For example BRSKI offers only enrollment service for an LDevID certificate. Management of other certificates is out of scope of BRSKI. A registrar offering generic RA functionality would need to distinguish between the different certificate types. BRSKI could for example utilize the arbitrary label to specify the LDevID certificate type or the CA it is to suppose to issue it.

The definition of the path segment "cmp" in CMP Updates or the more specific operation labels, e.g., " initialization" for http or "ir" for coap, in Lightweight CMP Profile prevent collision with other content on the RA/CA or on a web server, e.g., documentation or the like, and offer a well structured URI.

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

I see three ways forward to tackle your issue, plus the option to accept the current specification :-).

1. 
Use the query element in the URI to express the content of the arbitraryLabel.
      example.com/.well-known/cmp
      example.com/.well-known/cmp?profile=profileName
      example.com/.well-known/cmp?ca=caName
      example.com/.well-known/cmp/operationLabel
      example.com/.well-known/cmp/operationLabel?profile=profileName
      example.com/.well-known/cmp/operationLabel?ca=caName

2.
Change the order of arbitraryLabel and operationLabel.
      example.com/.well-known/cmp
      example.com/.well-known/cmp/operationLabel
      example.com/.well-known/cmp/arbitraryLabel
      example.com/.well-known/cmp/operationLabel/arbitraryLabel

3.
Give up using a /.well-known/ URI, possibly combined with solution 1 and 2.
      example.com/cmp
      example.com/cmp/operationLabel
      example.com/cmp/arbitraryLabel
      example.com/cmp/arbitraryLabel /operationLabel

4.
Do not change anything to be aligned with the approach from EST.

What I dislike about proposal 2 is, that it may confuse implementers, as the orders operationLabel and arbitraryLabel is different to the order specified for EST.
I dislike proposal 3, as I liked to have a well defined path segment used for CMP protocol endpoints.

Does anyone have opinions on these proposals?

Hendrik

> > > 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
> > > 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
> >    1.
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > example.com%2F.well-
> known%2Fest%2Fcacerts&amp;data=04%7C01%7Chendrik.b
> >
> rockhaus%40siemens.com%7C8a6420277bd348c6861b08d9f1a42e6c%7C38ae
> 3bcd95
> >
> 794fd4addab42e1495d55a%7C1%7C0%7C637806509737370525%7CUnknown
> %7CTWFpbG
> >
> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
> n0%
> >
> 3D%7C3000&amp;sdata=Ava58spSAMOM0KnNKIsMy0LR4TDmUpozu7ErsgdlT
> ys%3D&amp
> > ;reserved=0
> >
> >    2.
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > example.com%2F.well-
> known%2Fest%2FarbitraryLabel1%2Fcacerts&amp;data=0
> >
> 4%7C01%7Chendrik.brockhaus%40siemens.com%7C8a6420277bd348c6861b0
> 8d9f1a
> >
> 42e6c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63780650973
> 7370525%
> >
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
> TiI6Ik
> >
> 1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=WV0n8BBfqMY0R9OqCh1TXR
> V7%2FzPmQT
> > rP5LtD3NY5Nw4%3D&amp;reserved=0
> >
> >    3.
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > example.com%2F.well-
> known%2Fest%2FarbitraryLabel2%2Fcacerts&amp;data=0
> >
> 4%7C01%7Chendrik.brockhaus%40siemens.com%7C8a6420277bd348c6861b0
> 8d9f1a
> >
> 42e6c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63780650973
> 7370525%
> >
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
> TiI6Ik
> >
> 1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=WYjgD3ZJl5V%2BzhMGdTVFS
> PzO1KdV3L
> > CzNOy7GIkAnmE%3D&amp;reserved=0
> >
> > 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 URI, e.g.,
> 'https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.e
> xample.com%2F&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com
> %7C8a6420277bd348c6861b08d9f1a42e6c%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C637806509737370525%7CUnknown%7CTWFpbGZsb3d
> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C3000&amp;sdata=QirARZYWEWP8Bh3vW2t0hC4cCPuUAQJXXoKPiYSrHKw
> %3D&amp;reserved=0', or the full operation path
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.e
> xample.com%2F.well-
> known%2Fcmp&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com
> %7C8a6420277bd348c6861b08d9f1a42e6c%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C637806509737370525%7CUnknown%7CTWFpbGZsb3d
> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C3000&amp;sdata=sw43ICQHH%2F%2F5VicZWkvmFt1GuKXfAprm6QWfQ6
> 3xgOI%3D&amp;reserved=0
> >
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.e
> xample.com%2F.well-
> known%2Fcmp%2FoperationLabel&amp;data=04%7C01%7Chendrik.brockhau
> s%40siemens.com%7C8a6420277bd348c6861b08d9f1a42e6c%7C38ae3bcd957
> 94fd4addab42e1495d55a%7C1%7C0%7C637806509737370525%7CUnknown%
> 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> LCJXVCI6Mn0%3D%7C3000&amp;sdata=ZII30%2FXZ%2Blpgf%2BeQ3lXAeMe2ik
> NyBEXkLXs7VGUSJuQ%3D&amp;reserved=0
> >
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.e
> xample.com%2F.well-
> known%2Fcmp%2FprofileLabel&amp;data=04%7C01%7Chendrik.brockhaus%
> 40siemens.com%7C8a6420277bd348c6861b08d9f1a42e6c%7C38ae3bcd95794
> fd4addab42e1495d55a%7C1%7C0%7C637806509737370525%7CUnknown%7C
> TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
> XVCI6Mn0%3D%7C3000&amp;sdata=1FRZmawKgb%2BCC5mxxZ8ENPG9y31Tt
> 5gRxDcoRs8xNqI%3D&amp;reserved=0
> >
> >
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.e
> > xample.com%2F.well-
> known%2Fcmp%2FprofileLabel%2FoperationLabel&amp;dat
> >
> a=04%7C01%7Chendrik.brockhaus%40siemens.com%7C8a6420277bd348c686
> 1b08d9
> >
> f1a42e6c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637806509
> 7373705
> >
> 25%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> LCJBTiI
> >
> 6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=WJtAZ3zVq1fiR%2BtEYtod
> LHx7Y1Y
> > FND1usqu8sK3kCHM%3D&amp;reserved=0
> >
> > The operational labels for usage with http are further specified in
> Lightweight CMP Profile §6.1 (and for coap see §6.2).
> > 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