(Replying to Felipe's comment from the thread "Re: [Acme] Adam Roach's
Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)")
On 08/30/2018 11:17 AM, Felipe Gasper wrote:
> Would it work to keep certificate fetches as plain GET?
>
> In shared hosting environments it’s common for a privileged process
to request certificates on behalf of user accounts. This avoids having
1,000s of ACME server registrations from a single server. While
certificates are generally made available within seconds, theoretically
the delay between request and issuance could be much longer (e.g., for
OV/EV), such that it might be prudent for that privileged process to
give the order ID to the user and have the user poll for the
certificate, e.g., via cron.
This use case makes sense, but I think it is not critical enough to
carve out an exception from the "GETs become POSTs" plan. If the ACME
implementation structures certificate fetches such that they are
enumerable, you would wind up again with the same sort of correlation
problem Adam brought up. You could make the certificate URLs
unpredictable, but then you've introduced a notion of capability
URLs[1], which breaks the notion of having a single authentication
system for ACME.
It seems just as possible for the unprivileged process to do the polling
for the certificate, and once it's ready, make it available on the
filesystem for the unprivileged user.
[1] https://www.w3.org/TR/capability-urls/
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
