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 < [email protected]> 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 <[email protected]> > Cc: [email protected];; Benjamin Kaduk <[email protected]>; > [email protected] > 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 <[email protected]> > > 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 <[email protected]> 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&data=04%7C01%7Chendrik.b > > > > > rockhaus%40siemens.com%7C8a6420277bd348c6861b08d9f1a42e6c%7C38ae3 > > bcd95 > > > > > 794fd4addab42e1495d55a%7C1%7C0%7C637806509737370525%7CUnknown% > > 7CTWFpbG > > > > > Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn > > 0% > > > > > 3D%7C3000&sdata=Ava58spSAMOM0KnNKIsMy0LR4TDmUpozu7ErsgdlTys > > %3D& > > > ;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&data=0 > > > > > 4%7C01%7Chendrik.brockhaus%40siemens.com%7C8a6420277bd348c6861b08 > > d9f1a > > > > > 42e6c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637806509737 > > 370525% > > > > > 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi > > I6Ik > > > > > 1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=WV0n8BBfqMY0R9OqCh1TXRV > > 7%2FzPmQT > > > rP5LtD3NY5Nw4%3D&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&data=0 > > > > > 4%7C01%7Chendrik.brockhaus%40siemens.com%7C8a6420277bd348c6861b08 > > d9f1a > > > > > 42e6c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637806509737 > > 370525% > > > > > 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi > > I6Ik > > > > > 1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=WYjgD3ZJl5V%2BzhMGdTVFSPz > > O1KdV3L > > > CzNOy7GIkAnmE%3D&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&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C > > 8a6420277bd348c6861b08d9f1a42e6c%7C38ae3bcd95794fd4addab42e1495d5 > > 5a%7C1%7C0%7C637806509737370525%7CUnknown%7CTWFpbGZsb3d8eyJWI > > joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300 > > 0&sdata=QirARZYWEWP8Bh3vW2t0hC4cCPuUAQJXXoKPiYSrHKw%3D& > > ;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&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7 > > C8a6420277bd348c6861b08d9f1a42e6c%7C38ae3bcd95794fd4addab42e1495d > > 55a%7C1%7C0%7C637806509737370525%7CUnknown%7CTWFpbGZsb3d8eyJ > > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C > > 3000&sdata=sw43ICQHH%2F%2F5VicZWkvmFt1GuKXfAprm6QWfQ63xgOI > > %3D&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&data=04%7C01%7Chendrik.brockhaus > > %40siemens.com%7C8a6420277bd348c6861b08d9f1a42e6c%7C38ae3bcd9579 > > 4fd4addab42e1495d55a%7C1%7C0%7C637806509737370525%7CUnknown%7C > > TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX > > VCI6Mn0%3D%7C3000&sdata=ZII30%2FXZ%2Blpgf%2BeQ3lXAeMe2ikNyBE > > XkLXs7VGUSJuQ%3D&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&data=04%7C01%7Chendrik.brockhaus%40 > > siemens.com%7C8a6420277bd348c6861b08d9f1a42e6c%7C38ae3bcd95794fd4 > > addab42e1495d55a%7C1%7C0%7C637806509737370525%7CUnknown%7CTWF > > pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6 > > Mn0%3D%7C3000&sdata=1FRZmawKgb%2BCC5mxxZ8ENPG9y31Tt5gRxDc > > oRs8xNqI%3D&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&dat > > > > > a=04%7C01%7Chendrik.brockhaus%40siemens.com%7C8a6420277bd348c6861 > > b08d9 > > > > > f1a42e6c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6378065097 > > 373705 > > > > > 25%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL > > CJBTiI > > > > > 6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=WJtAZ3zVq1fiR%2BtEYtodL > > Hx7Y1Y > > > FND1usqu8sK3kCHM%3D&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 >
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
