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

>
> In short, I think certificates should be POST-as-GET just like the other
> resources.

+1. If we're replacing the GETs to Orders, Authorizations and Challenges
there's no sense in excluding Certificates. I prefer the uniformity over
exceptions for use-cases that don't have strong real-world
use/implementations.

On Fri, Aug 31, 2018 at 3:30 PM, Jacob Hoffman-Andrews <jsha@eff.org> 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.
>
> 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.
>
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>