Re: [Acme] ACME breaking change: Most GETs become POSTs

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 <felipe@felipegasper.com>
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 <rlb@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 <felipe@felipegasper.com>
> wrote:
> >
> >
> > > On Aug 30, 2018, at 7:48 PM, Jacob Hoffman-Andrews <jsha@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
>
>