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
