To be clear, I'm proposing that the server MUST allow GET for a certificate resource (as well as POST-as-GET). It can protect those GETs with capability URLs if it wants to.
On Fri, Aug 31, 2018 at 10:21 AM Felipe Gasper <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> > wrote: > > > > > > > On Aug 30, 2018, at 7:48 PM, Jacob Hoffman-Andrews <[email protected]> > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/acme > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
