Re: [art] On BCP 190

[Larry Masinter <[e-mail]>]

Although it might seem like overkill, JSON HAL 

https://tools.ietf.org/html/draft-kelly-json-hal-08

seems like it’s intended as a way of avoiding having

the client do string-hacking of URL paths

(EXCEPT processing relative URLs and constructing
GET URLs on some kinds of form submissions).

 

The use of / in the path of URLs was supposed to

be restricted to hierarchical data, and yet CT doesn’t
do that.

http://masinter.blogspot.com/2019/05/on-nature-of-hierarchical-urls.html 

 

Now, why JSON-HAL is still an expired  Internet Draft 

is a puzzle.

--

https://LarryMasinter.net 

 

 

From: art <[e-mail]> On Behalf Of Jacob Hoffman-Andrews
Sent: Wednesday, July 24, 2019 10:49 AM
To: Mark Nottingham <[e-mail]>
Cc: ART Area <[e-mail]>; Devon O'Brien <[e-mail]>
Subject: Re: [art] On BCP 190

 

On Wed, Jul 24, 2019 at 10:24 AM Mark Nottingham <[e-mail] <mailto:[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