I agree with Jacob here. As I have expressed in the past, I believe that this is a better design than the well-known prefix.
On Fri, Jun 21, 2019, at 08:33, Jacob Hoffman-Andrews wrote: > The latest draft adopts a /.well-known/ path for CT as a way to get > around BCP 190 (URI Design and Ownership: > https://tools.ietf.org/html/bcp190#section-3). > > Personally I think BCP 190 makes it needlessly painful to specify > HTTP-based APIs using techniques that are very common among > practitioners. However, given that it is still considered best practice > for IETF documents, I propose that CT should use a different workaround, > one used very successfully by ACME: Directory URLs. > > In ACME, a CA defines one URL, a Directory, which provides a JSON > dictionary showing where to find the other URLs. For instance: > > $ curl https://acme-v01.api.letsencrypt.org/directory > { > "fUKGu3pAntw": > "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417";, > "key-change": "https://acme-v01.api.letsencrypt.org/acme/key-change";, > "meta": { > "caaIdentities": [ > "letsencrypt.org" > ], > "terms-of-service": > "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf";, > "website": "https://letsencrypt.org"; > }, > "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz";, > "new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert";, > "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg";, > "revoke-cert": > "https://acme-v01.api.letsencrypt.org/acme/revoke-cert"; > } > > To use an ACME CA, rather than configuring a base URL, an ACME client > configures a directory URL. All other URLs can be found by looking up > fields in the directory. > > Adding a directory to rfc6962-bis provides the most minimally invasive > way to satisfy BCP 190. Well-known URLs aren't really meant for this > type of application. To quote RFC 5785 > (https://tools.ietf.org/html/rfc5785#section-1.1): > > 1.1. Appropriate Use of Well-Known URIs > > There are a number of possible ways that applications could use > Well- > known URIs. However, in keeping with the Architecture of the World- > Wide Web [W3C.REC-webarch-20041215], *well-known URIs are not > intended** > ** for general information retrieval or establishment of large URI** > ** namespaces* on the Web. Rather, they are designed to facilitate > discovery of information on a site when it isn't practical to use > other mechanisms; for example, when discovering policy that needs to > be evaluated before a resource is accessed, or when using multiple > round-trips is judged detrimental to performance. > > As such, the well-known URI space was created with the expectation > that it will be used to make site-wide policy information and other > metadata available directly (if sufficiently concise), or provide > references to other URIs that provide such metadata. > > (emphasis mine) > > Beyond that, requiring log operators to organize their log under > /.well-known/ would pose unnecessary difficulties. Service providers > intentionally restrict the /.well-known/ URL space. Depending on > deployment model, log operators might have to bypass such restrictions > or get special exemptions. > > Thanks, > Jacob > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans > _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
