> 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
