Benjamin Kaduk <[email protected]> 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 protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
