I also think .well-known URLs are a bad idea, for the same reasons as Jacob.
I think directories are even worse. Although they've been used successfully in ACME, CT has different needs which make directories unsuitable. ACME's usage pattern is to make a series of related requests over a short time period to drive a certificate request to issuance, with the client maintaining state between each request. This makes it natural for a client to fetch the directory once at the beginning of an issuance "session" and use it for the duration, since the cost of fetching the directory is amortized over all the requests, and the directory is unlikely to become invalid during the session. However, CT's usage pattern is to make a lot of unrelated one-off requests spread over a long period of time - e.g. submitting a (pre)certificate, fetching an inclusion proof, fetching the latest STH to send to auditors. Clients would have to either fetch a new directory for every request (doubling the number of requests made to the log) or cache directories in long-term state (which requires dealing with cached directories going stale, and requires keeping long-term state which might not otherwise be necessary). ACME's use of directories is underspecified since it doesn't say how long a directory remains valid. It's not a big deal for ACME because ACME servers are presumed to be sane, or people would switch to another CA. However, CT is meant to be an adversarial protocol and has to anticipate logs doing crazy things like constantly changing their directory in an effort to stymie auditing and hide misbehavior. Thus, CT's use of directories would need to be quite well specified. It is not a change that should be rushed at the last minute without a chance for people to carefully examine and poke holes in it. CT clients already need to be configured with a number of parameters for each log - MMD, hash algorithm, public key, log ID, and so on. Adding a directory would bifurcate log metadata between the existing parameter set and the new directory object. I propose satisfying BCP 190 by simply specifying the URL for each endpoint as a separate log parameter. This is a very minimal change to the protocol and avoids the problems above. Regards, Andrew _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
