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

[Jacob Hoffman-Andrews <[e-mail]>]

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.

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.