Hello, > 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.
what happens if the cert URL is not https://example.com/acme/cert/somerandomlookingidentifier, but https://example.com/acme/acct/2/order/1/cert? Then someone can still do identification correlation when the certificate can be downloaded without authentication. Cheers, Felix > > , 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 Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
