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 <ka...@mit.edu>
> 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.
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.
>
> 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.
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.
> 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.
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
>
> -Ben
>
> > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > example.com%2F.well-
> known%2Fest%2Fcacerts&data=04%7C01%7Chendrik.b
> >
> rockhaus%40siemens.com%7C8a6420277bd348c6861b08d9f1a42e6c%7C38ae
> 3bcd95
> >
> 794fd4addab42e1495d55a%7C1%7C0%7C637806509737370525%7CUnknown
> %7CTWFpbG
> >
> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
> n0%
> >
> 3D%7C3000&sdata=Ava58spSAMOM0KnNKIsMy0LR4TDmUpozu7ErsgdlT
> ys%3D&
> > ;reserved=0
> >
> > 2.
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > example.com%2F.well-
> known%2Fest%2FarbitraryLabel1%2Fcacerts&data=0
> >
> 4%7C01%7Chendrik.brockhaus%40siemens.com%7C8a6420277bd348c6861b0
> 8d9f1a
> >
> 42e6c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63780650973
> 7370525%
> >
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
> TiI6Ik
> >
> 1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=WV0n8BBfqMY0R9OqCh1TXR
> V7%2FzPmQT
> > rP5LtD3NY5Nw4%3D&reserved=0
> >
> > 3.
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > example.com%2F.well-
> known%2Fest%2FarbitraryLabel2%2Fcacerts&data=0
> >
> 4%7C01%7Chendrik.brockhaus%40siemens.com%7C8a6420277bd348c6861b0
> 8d9f1a
> >
> 42e6c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63780650973
> 7370525%
> >
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
> TiI6Ik
> >
> 1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=WYjgD3ZJl5V%2BzhMGdTVFS
> PzO1KdV3L
> > 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://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.e
> xample.com%2F&data=04%7C01%7Chendrik.brockhaus%40siemens.com
> %7C8a6420277bd348c6861b08d9f1a42e6c%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C637806509737370525%7CUnknown%7CTWFpbGZsb3d
> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C3000&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://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.e
> xample.com%2F.well-
> known%2Fcmp&data=04%7C01%7Chendrik.brockhaus%40siemens.com
> %7C8a6420277bd348c6861b08d9f1a42e6c%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C637806509737370525%7CUnknown%7CTWFpbGZsb3d
> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C3000&sdata=sw43ICQHH%2F%2F5VicZWkvmFt1GuKXfAprm6QWfQ6
> 3xgOI%3D&reserved=0
> >
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.e
> xample.com%2F.well-
> known%2Fcmp%2FoperationLabel&data=04%7C01%7Chendrik.brockhau
> s%40siemens.com%7C8a6420277bd348c6861b08d9f1a42e6c%7C38ae3bcd957
> 94fd4addab42e1495d55a%7C1%7C0%7C637806509737370525%7CUnknown%
> 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> LCJXVCI6Mn0%3D%7C3000&sdata=ZII30%2FXZ%2Blpgf%2BeQ3lXAeMe2ik
> NyBEXkLXs7VGUSJuQ%3D&reserved=0
> >
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.e
> xample.com%2F.well-
> known%2Fcmp%2FprofileLabel&data=04%7C01%7Chendrik.brockhaus%
> 40siemens.com%7C8a6420277bd348c6861b08d9f1a42e6c%7C38ae3bcd95794
> fd4addab42e1495d55a%7C1%7C0%7C637806509737370525%7CUnknown%7C
> TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
> XVCI6Mn0%3D%7C3000&sdata=1FRZmawKgb%2BCC5mxxZ8ENPG9y31Tt
> 5gRxDcoRs8xNqI%3D&reserved=0
> >
> >
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.e
> > xample.com%2F.well-
> known%2Fcmp%2FprofileLabel%2FoperationLabel&dat
> >
> a=04%7C01%7Chendrik.brockhaus%40siemens.com%7C8a6420277bd348c686
> 1b08d9
> >
> f1a42e6c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637806509
> 7373705
> >
> 25%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> LCJBTiI
> >
> 6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=WJtAZ3zVq1fiR%2BtEYtod
> LHx7Y1Y
> > 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
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
