Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

[Adam Roach <[e-mail]>]

On 8/30/18 7:55 AM, Richard Barnes wrote:
> Focusing on DISCUSS comment for now, will pick up COMMENTs later.
>
> On your DISCUSS, I think you're off on a couple of small things


Yeah, I woke up with the sudden realization that I'd had the wrong model 
in my head when I talked through the cert endpoint. All that's there is 
a signed public cert rather than a public/private pair, so it's not 
sensitive.


> , but right on the underlying point that the document doesn't really 
> provide any guidance as to which resources a server should consider 
> sensitive.  I agree that it would be good to say more, and I've 
> started up a PR for this.
>
> https://github.com/ietf-wg-acme/acme/pull/443


Thanks -- that fixes the text I cite.


>
> I don't agree that sensitivity entails a need for non-guessable URLs.  
> If accessing the URL requires authentication, then it doesn't matter 
> if someone can guess it; unauthorized people can't access it even if 
> they can guess it.  I guess you could argue that if you made a random 
> URL and only distributed it in authenticated channels, then you could 
> allow GETs to it, using the URL itself as an authenticator.  But that 
> seems super brittle; I would rather just have all the authentication 
> be based on signing.  So at best, random URLs are a backstop against a 
> CA making the wrong decision about GETs.


Yup, that seems better.


>
> You're also correct to note that some resources might be sensitive 
> that we now instruct clients to poll with GETs. For example, the 
> client is supposed to poll an authorization resource to see when it 
> validates, but if the authz has a TN in it and so is considered 
> sensitive, you won't be able to do a GET.  I think the right answer 
> here is to have the server return 405 Method Not Allowed if it gets a 
> GET and have the client fall back to an authenticated "POST {}", which 
> should be equivalent to a GET in all cases.


That seems like a good clarification. The one remaining issue is the 
table at the bottom of §7.1, which shows GETs for resources that the new 
text says CAs might consider sensitive. I catch the "might" in that 
sentence, but it seems that identification correlation is a pretty 
powerful privacy leak, and would strongly suggest that the table be 
revised to show POSTs for retrieval of order resources. Whether you take 
this suggestion is up to you -- I'll clear my DISCUSS either way.

/a