> > 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 <j...@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 >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
