I wonder, then, if it’s worth making it discoverable whether the server allows a plain GET for a certificate … other than, of course, getting a 405 back when the client tries to request a certificate via GET.
-F > On Aug 31, 2018, at 10:16 AM, Richard Barnes <r...@ipv.sx> wrote: > > 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
