Re: [Trans] Directory instead of .well-known for URL structure

["Martin Thomson" <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trans
>