+1 for not liking .well-known URIs. From an implementor, .well-known URIs have been hard, probably badly designed (i.e. RFC 7030), simply making multi-tenancy, or multi-configuration hard by enforcing a single end-point for each FQDN. We're actually bypassing .well-known, making it possible to use normal URLs instead in some cases (in addition to the specified and limited .well-known of course)
Agree with Andrew, with CT where you need to get and configure parameters from the log anyhow, and getting the URL as part of that is the most flexible way. This allows the server operator/implementor full freedom in their architecture, load balancing, etc. Regards, Tomas On 2019-07-01 21:37, Andrew Ayer wrote: > 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 > _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
