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

[Mohit Sahni <[e-mail]>]

Hi Hendrik
The draft expired last month and I will publish a new version with changes
catering to Ben's comments. I apologize to everyone for slacking on this
draft due to some ongoing personal issues.

Regards
Mohit

On Thu, Jul 7, 2022 at 10:54 PM Brockhaus, Hendrik <
[e-mail]> wrote:

> WG ACE
>
> After approval of CMP Updates at IESG last week, I would appreciate
> progress on this draft, as it is blocking publication of CMP Updates.
> I haven't seen any progress for a while and the current version of the
> draft is outdated.
> What is the status and the current timeline of the document in ACE?
>
> Hendrik
>
> -----Ursprüngliche Nachricht-----
> Von: Brockhaus, Hendrik (T CST SEA-DE)
> Gesendet: Freitag, 15. April 2022 17:07
> An: Mohit Sahni <[e-mail]>
> Cc: [e-mail];; Benjamin Kaduk <[e-mail]>;
> [e-mail]
> Betreff: AW: [Ace] AD review of draft-ietf-ace-cmpv2-coap-transport-04
>
> 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://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww__;JSUl!!Mt_FR42WkD9csi9Y!Z8DfJbXNFzm1NU0YAP0dvSZSKIL0Wj9lCdrTSEQ-VIF4ZOsnbLGjeV4x-xhEFcdXetxtP09fJB9nIyI5IlYEEN-NEMPgECfsOg$
> .
> > > 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://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww__;JSUl!!Mt_FR42WkD9csi9Y!Z8DfJbXNFzm1NU0YAP0dvSZSKIL0Wj9lCdrTSEQ-VIF4ZOsnbLGjeV4x-xhEFcdXetxtP09fJB9nIyI5IlYEEN-NEMPgECfsOg$
> .
> > > 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://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww__;JSUl!!Mt_FR42WkD9csi9Y!Z8DfJbXNFzm1NU0YAP0dvSZSKIL0Wj9lCdrTSEQ-VIF4ZOsnbLGjeV4x-xhEFcdXetxtP09fJB9nIyI5IlYEEN-NEMPgECfsOg$
> .
> > > 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://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.com/?url=http*3A*2F*2Fwww__;JSUl!!Mt_FR42WkD9csi9Y!Z8DfJbXNFzm1NU0YAP0dvSZSKIL0Wj9lCdrTSEQ-VIF4ZOsnbLGjeV4x-xhEFcdXetxtP09fJB9nIyI5IlYEEN-NEMNrTbTCIw$
> .
> > 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://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.com/?url=http*3A*2F*2Fwww.e__;JSUl!!Mt_FR42WkD9csi9Y!Z8DfJbXNFzm1NU0YAP0dvSZSKIL0Wj9lCdrTSEQ-VIF4ZOsnbLGjeV4x-xhEFcdXetxtP09fJB9nIyI5IlYEEN-NEMMvgfw4Ow$
> > xa
> > 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://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.com/?url=http*3A*2F*2Fwww.e__;JSUl!!Mt_FR42WkD9csi9Y!Z8DfJbXNFzm1NU0YAP0dvSZSKIL0Wj9lCdrTSEQ-VIF4ZOsnbLGjeV4x-xhEFcdXetxtP09fJB9nIyI5IlYEEN-NEMMvgfw4Ow$
> > xa
> > 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://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.com/?url=http*3A*2F*2Fwww.e__;JSUl!!Mt_FR42WkD9csi9Y!Z8DfJbXNFzm1NU0YAP0dvSZSKIL0Wj9lCdrTSEQ-VIF4ZOsnbLGjeV4x-xhEFcdXetxtP09fJB9nIyI5IlYEEN-NEMMvgfw4Ow$
> > xa
> > 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://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.com/?url=http*3A*2F*2Fwww__;JSUl!!Mt_FR42WkD9csi9Y!Z8DfJbXNFzm1NU0YAP0dvSZSKIL0Wj9lCdrTSEQ-VIF4ZOsnbLGjeV4x-xhEFcdXetxtP09fJB9nIyI5IlYEEN-NEMNrTbTCIw$
> > > .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
>