Re: [art] On BCP 190

[Mark Nottingham <[e-mail]>]

On 24 Jul 2019, at 12:51 pm, Jacob Hoffman-Andrews <[e-mail]> wrote:
> 
> So CT is totally fine with regards to this part of BCP 190 Section 2.3:
> 
> >    For example, an application ought not specify a fixed URI path
> >   "/myapp", since this usurps the host's control of that space.

Yep.


> It's this part of BCP 190 Section 2.3 that is causing the issue:
> 
> >  Specifying a fixed path relative to another (e.g., {whatever}/myapp)
> >  is also bad practice (even if "whatever" is discovered as suggested
> >   in Section 3); while doing so might prevent collisions, it does not
> >   avoid the potential for operational difficulties (for example, an
> >   implementation that prefers to use query processing instead, because
> >   of implementation constraints).
> 
> To be clear, the "whatever" in this case is referred to as <log server> in CT, and is discovered via the known logs list (https://www.certificate-transparency.org/known-logs) and browser CT programs.

Yes -- and this text should definitely be considered when revising 190. Like I said, we've moved on a fair amount since then (although we still have a ways to go). 

One thing I'd like to see in a revision is a clearer separation between "you're potentially harming others by doing this; don't do it" and "you're potentially harming yourself by doing this; think carefully before proceeding."


> On Tue, Jul 23, 2019 at 11:14 AM Mark Nottingham <[e-mail]> wrote:
> common practices for an API that's implemented once and deployed on one server that's under the control of the designer (e.g., api.twitter.com) are often not appropriate for an API that is implemented many times, deployed on many servers owned by different people, and sometimes evolved independently
> 
> This is a valuable and subtle point, and I think the crux of the matter. It's actually surprisingly rare to see an HTTP API that is designed to be implemented many times. But if you look at those that are (RFC 7482, RFC 7808, RFC 8040, Mastodon, and Git, for example), what they have in common is that they are all organized around a hostname and path prefix, just like CT.

Agreed. 

The discussion I had with Devon the other day led to two paths (not that there aren't others; these just seem most likely as ways forward):

1) Using .well-known. This is precisely what well-known is for, and if hosting multiple logs is a concern, you can just require that /.well-known/mumble/ be the prefix you use; e.g., you could use something like /.well-known/ct-logs/2019/ as a prefix if you want to shard by year.

2) Getting an exception. 

AFAICT the arguments against #1 are:

a) that some people don't have access to .well-known on their servers -- but this seems like a very poor argument for this particular use case.

b) aesthetic   ¯\_(ツ)_/¯

#2's main downside is the process of getting the exception and agreeing on text. FWIW I'm happy to support an exception here (but would be happier if someone could explain why #1 isn't a sufficient option), and help come up with a small bit of text. You might want to talk to ADs about how much process they want to impose before walking down this path, but I can't see it taking that long personally.

Cheers,

--
Mark Nottingham   https://www.mnot.net/