TBH, I'm not averse to allowing GETs for certificate resources. It seems analogous to allowing them for the directory resource, just on the opposite side of the process. That is, the directory and certificate resources are the interfaces between ACME and the outside world, so it makes sense not to force the outside world into the ACME authentication model. In the same vein, capability URLs could be sensible here as an optional protection, since they're an authn model that's easy for the outside world to use.
In addition, the content of certificate resources is tightly constrained, so we don't have the problem that we have with the JSON resources, that a server might add some information that violates privacy expectations. So I would propose that we say: - GETs are allowed for directory, newNonce, and certificate resources - Servers MUST still respond to POST-as-GET requests for certificates, to simplify client logic - If a server is concerned about the privacy of certificate resources, then they SHOULD assign them capability URLs. I'll be updating the PR to reflect some comments in Github a little later today, and will incorporate the above unless people think it's awful. --Richard On Thu, Aug 30, 2018 at 8:46 PM Felipe Gasper <fel...@felipegasper.com> wrote: > > > > On Aug 30, 2018, at 7:48 PM, Jacob Hoffman-Andrews <j...@eff.org> wrote: > > > > (Replying to Felipe's comment from the thread "Re: [Acme] Adam Roach's > Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)") > > > > On 08/30/2018 11:17 AM, Felipe Gasper wrote: > > > Would it work to keep certificate fetches as plain GET? > > > > > > In shared hosting environments it’s common for a privileged process to > request certificates on behalf of user accounts. This avoids having 1,000s > of ACME server registrations from a single server. While certificates are > generally made available within seconds, theoretically the delay between > request and issuance could be much longer (e.g., for OV/EV), such that it > might be prudent for that privileged process to give the order ID to the > user and have the user poll for the certificate, e.g., via cron. > > > > This use case makes sense, but I think it is not critical enough to > carve out an exception from the "GETs become POSTs" plan. If the ACME > implementation structures certificate fetches such that they are > enumerable, you would wind up again with the same sort of correlation > problem Adam brought up. You could make the certificate URLs unpredictable, > but then you've introduced a notion of capability URLs[1], which breaks the > notion of having a single authentication system for ACME. > > I suppose if I have: > > GET /order/123/certificate => cert for yin.com > > GET /order/124/certificate => cert for yang.com > > … then one could surmise (however justifiably) that these two may be > related, so I see the point. > > > You could make the certificate URLs unpredictable, but then you've > introduced a notion of capability URLs[1], which breaks the notion of > having a single authentication system for ACME. > > I can see that. > > > Thanks for your consideration! > > -FG > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
