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
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
