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
[email protected]
https://www.ietf.org/mailman/listinfo/acme
