Re: [art] On BCP 190

[Jacob Hoffman-Andrews <[e-mail]>]

On Wed, Jul 24, 2019 at 10:24 AM Mark Nottingham <[e-mail]> wrote:

> > 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."
>

Which category to you think that paragraph of Section 2.3 (call it 2.3b)
belongs to? It sounds like it belongs to the "harming yourself" category,
which means that it's not actually protecting a commons.

And to be clear, even though 2.3b sounds advisory-only, it's this clause at
the top of Section 2.3 that has broader normative language:

> specifications MUST NOT constrain,
>   or define the structure or the semantics for any path component.


> 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.
>

Andrew Ayer presented one concrete case where the use of .well-known
presented implementation difficulties for Google, a company that presumably
has full control over its servers. I don't know the details of why, but I
can guess: .well-known is dangerous. As a hosting provider, allowing users
to upload abritrary files to /.well-known/acme-challenge means the users
can get certificates for the hosted domain name. Probably there are other
security-relevant things under /.well-known/. The safe and reasonable thing
is to just block access to /.well-known/. I would guess that Google's
security team has set a policy: All access to .well-known is blocked at the
frontends unless it's gone through a detailed review.

So we have advice in BCP 190 meant to ensure that protocols allow
implementers to implement any way they want (e.g. with query parameters to
represent semantics). But instead, the advice to require /.well-known/ is
creating practical barriers for implementers to implement things in the way
they want.

Also, if the reasoning for 2.3b is that implementers might only be able to
use query parameters, not paths, then specifying paths under .well-known
doesn't solve that problem at all.

Thanks,
Jacob