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

[Andrew Ayer <[e-mail]>]

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