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

["Brockhaus, Hendrik" <[e-mail]>]

Mohit

After discussing the issue regarding well-known URI path segments on email and during IETF113 LAMPS meeting, I updated the CMP Updates document reflecting the agreed solution.
The solution is registering a well-known CMP registry. CMP Updates will register the path segment 'p' that is defined to be followed by a CA or certificate profile name.
The path segments for usage with http and coap defining the PKI management operations will be registered by Lightweight CMP Profile.

You can update the CoAP Transfer for CMP draft accordingly and align it with the changes describes above.

If you have any questions, please feel free to contact me.

Hendrik

> Von: Benjamin Kaduk <[e-mail]>
> Gesendet: Donnerstag, 17. Februar 2022 00:29
> 
> 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 <[e-mail]> 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://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%7C38ae3
> bcd95
> >
> 794fd4addab42e1495d55a%7C1%7C0%7C637806509737370525%7CUnknown%
> 7CTWFpbG
> >
> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> 0%
> >
> 3D%7C3000&amp;sdata=Ava58spSAMOM0KnNKIsMy0LR4TDmUpozu7ErsgdlTys
> %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%7C8a6420277bd348c6861b08
> d9f1a
> >
> 42e6c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637806509737
> 370525%
> >
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
> I6Ik
> >
> 1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=WV0n8BBfqMY0R9OqCh1TXRV
> 7%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%7C8a6420277bd348c6861b08
> d9f1a
> >
> 42e6c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637806509737
> 370525%
> >
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
> I6Ik
> >
> 1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=WYjgD3ZJl5V%2BzhMGdTVFSPz
> O1KdV3L
> > CzNOy7GIkAnmE%3D&amp;reserved=0
> >
> > 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.,
> 'https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.exa
> mple.com%2F&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C
> 8a6420277bd348c6861b08d9f1a42e6c%7C38ae3bcd95794fd4addab42e1495d5
> 5a%7C1%7C0%7C637806509737370525%7CUnknown%7CTWFpbGZsb3d8eyJWI
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300
> 0&amp;sdata=QirARZYWEWP8Bh3vW2t0hC4cCPuUAQJXXoKPiYSrHKw%3D&amp
> ;reserved=0', 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:
> >
> >
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.exa
> mple.com%2F.well-
> known%2Fcmp&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7
> C8a6420277bd348c6861b08d9f1a42e6c%7C38ae3bcd95794fd4addab42e1495d
> 55a%7C1%7C0%7C637806509737370525%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> 3000&amp;sdata=sw43ICQHH%2F%2F5VicZWkvmFt1GuKXfAprm6QWfQ63xgOI
> %3D&amp;reserved=0
> >
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.exa
> mple.com%2F.well-
> known%2Fcmp%2FoperationLabel&amp;data=04%7C01%7Chendrik.brockhaus
> %40siemens.com%7C8a6420277bd348c6861b08d9f1a42e6c%7C38ae3bcd9579
> 4fd4addab42e1495d55a%7C1%7C0%7C637806509737370525%7CUnknown%7C
> TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> VCI6Mn0%3D%7C3000&amp;sdata=ZII30%2FXZ%2Blpgf%2BeQ3lXAeMe2ikNyBE
> XkLXs7VGUSJuQ%3D&amp;reserved=0
> >
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.exa
> mple.com%2F.well-
> known%2Fcmp%2FprofileLabel&amp;data=04%7C01%7Chendrik.brockhaus%40
> siemens.com%7C8a6420277bd348c6861b08d9f1a42e6c%7C38ae3bcd95794fd4
> addab42e1495d55a%7C1%7C0%7C637806509737370525%7CUnknown%7CTWF
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C3000&amp;sdata=1FRZmawKgb%2BCC5mxxZ8ENPG9y31Tt5gRxDc
> oRs8xNqI%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%7C8a6420277bd348c6861
> b08d9
> >
> f1a42e6c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6378065097
> 373705
> >
> 25%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI
> >
> 6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=WJtAZ3zVq1fiR%2BtEYtodL
> Hx7Y1Y
> > 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).
> >    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