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.

-Felipe Gasper
Mississauga, Ontario


> On Aug 30, 2018, at 11:51 AM, Salz, Rich <rsalz=40akamai....@dmarc.ietf.org> 
> wrote:
> 
> It appears that we missed a security issue.
>  
> Please take a look at the PR mentioned below.  It removes many GET requests 
> and turns them into POST so that the client payload can have authentication 
> information.
>  
> If you object to this change, please post a note to the list and explain why. 
>  Try to do that within a week.
>  
> Thanks.
>  
> From: Richard Barnes <r...@ipv.sx>
> Date: Thursday, August 30, 2018 at 11:42 AM
> To: Adam Roach <a...@nostrum.com>
> Cc: "felix=40fontein...@dmarc.ietf.org" <felix=40fontein...@dmarc.ietf.org>, 
> "acme@ietf.org" <acme@ietf.org>
> Subject: Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with 
> DISCUSS and COMMENT)
>  
> My preference here would be for approach (1).  I appreciate that it's a big 
> change to make this late in the process, but that's the price we pay for 
> missing a pretty significant issue up until now.  For existing 
> implementations, the code impact should be modest, as long as they have been 
> architected to isolate fetch logic (i.e., the have a get() method that you 
> could just change to do the right POST thing).  And as long as we don't 
> *forbid* responding to GET requests, servers can support both options for the 
> time being.
>  
> To illustrate what change we'd need to make, I went ahead and wrote up a PR:
>  
> https://github.com/ietf-wg-acme/acme/pull/445
>  
> _______________________________________________
> 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

Reply via email to