Closed vanbroup closed 4 months ago
The main point here is that if this draft requires hosting providers (who operate the automated ACME client) to blindly accept the TOS of arbitrary ACME servers, then this draft will never proceed.
We need to be sure that the person who needs to accept the ACME TOS is the domain owner and not the ACME client operator.
I think we are ok on this point, but it is worth more consideration, and clarification of the text.
Some more useful text that Paul wrote:
If the terms of service limit usage to non-commercial use, the domain owner should not set the CAA record if they run a commercial service, the domain owner is the entity giving the instruction to the ACME client and thus requests the certificate from the CA and be bound to the terms of service.
https://mailarchive.ietf.org/arch/msg/acme/5CQLiuUN8yaPN4u_LmSAC1yqDu0/
Also a similar comment from Q Missel:
Might it be worth spelling out in the I-D the author's intentions about who is the holder of the account. This would also help clarify who is actually agreeing to the CA ToS.
https://mailarchive.ietf.org/arch/msg/acme/-KBunXt1BN6GIAKRSraw_IXqfbw/
We believe this is fully and properly addressed by Implementation Consideration 7.2, hence closing this issue.
In the security considerations we describe currently two mechanisms, implicit approval by setting the CAA record, or explicit approval by including a CAA parameter.
Add that if a CA would like to get an explicit approval, they could also send a request to the ACME account email to approve the terms of service before activating the ACME account.
Where a CA is using an external account binding the terms of service have already been agreed to for the CA account.