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

[Richard Barnes <[e-mail]>]

On Fri, Aug 31, 2018 at 3:30 PM Jacob Hoffman-Andrews <[e-mail]> wrote:

> On 08/31/2018 07:25 AM, Richard Barnes wrote:
> > The problem with using POST-as-GET for certificate resources, as
> > Felipe I think pointed out, is that the thing that downloads the
> > certificate URL is often not an ACME player, doesn't have an account,
> > etc.  It's a web server or something. (cf. the STAR drafts.)  What I'm
> > saying is that it's painful to make them integrate with ACME and we
> > don't get any benefit.
> AFAIK, no current ACME client hands off certificate URLs to
> less-privileged processes.
>
> Keeping GETs for certificates undermines the goal of making the
> POST-as-GET change. Certificate resources may be constructed in
> enumerable ways, like:
>
> /account/100/certificate/3438
> /account/201/certificate/3439
> /account/100/certificate/3440*
>
> While many CAs may not consider correlation of certificates by account
> to be sensitive, our goal with this change is to eliminate a footgun for
> CAs who do consider it sensitive, by simply ensuring all requests are
> authenticated by default. Consistent authentication also has the
> potential to simplify by client and server libraries.
>
> I think it would be a mistake to carve out this exception in the main
> ACME spec for use cases that are still speculative. Instead, if there is
> a use case that truly requires unauthenticated certificate retrieval, it
> should be defined as an extension or an optional feature.
>

I understand the desire for uniformity; I'm just concerned we're going
overboard here.

I could live with this being optional, but I would prefer to go ahead and
add it (because STAR needs it) and keep the negotiation minimal.  I would
propose that we just say the server MAY accept GETs for certificate URLs,
returning 405 if not.

That way a client with a GET-based use case would have to either find out
out of band that the server was compatible, or else fail when it tries.
But that seems like an acceptable outcome to me.  If we need an "I always
do cert+GET" signal, we can toss it in the "meta" dictionary later.

--Richard


>
> In short, I think certificates should be POST-as-GET just like the other
> resources.
>
> *Note: I'm aware that certificate serial numbers must be randomized, but
> there is no requirement that the certificate serial number be present in
> the URL.
>