Draft: draft-ietf-acme-acme

Commentary: It would be nice if it could be clarified whether " --agree - tos"-like switches that do n't require the user to whitelist specific TOS versions are acceptable in ACME clients . certbot has one . On the other hand , the author of acmetool refuses to implement " --agree - tos"-like functionality without clarification in the spec , making it impossible to completely automate renewal with certbot . ( hlandau / acme ) . If it is n't acceptable then we have the absurd situation of the de - facto official client being out of spec . ( Note : I accidentally opened the issue against the wrong repo first ( ) . ) 
 There 's a limit to what we can do here , because switches like this are not part of the protocol . We can say , however , that clients SHOULD NOT auto - agree by default ( so that there 's some user interaction at some point , even just at config time ) , and that CAs need to keep in mind that clients can automate . I 'll post a PR shortly . 
 Thanks for the quick reply , but pr does n't really answer the question . The question was n't about the default case ( ie , it 's not about doing away with --agree - tos entirely ) , but about giving users the choice to blanket accept future versions of TOS by continued usage , after the initial configuration / initial acceptance of TOS , instead of having to change a config file everytime a new TOS is rolled out . From your answer and PR , I 'm still not sure what your opinion on that question is . 
 Note that the protocol specifically handles only initial acceptance . If the CA wants a user to explicitly agree to a new  ( this is exceptionally rare - most ToS have auto - update language ) , it does so by sending an error message with a link to a webpage with instructions for agreeing anew . So the only question that needs to be answered is whether a user can specify agreement to the current terms on initially running the client . 
 LE does it , breaking users renewals ( for acmetool users ) . I 'm concerned with automating renewals ( and also automated from - scratch deployments ) , and this issue is specifically about keeping setups working without manual intervention . This is currently possible with certbot and not possible with acmetool , because the author is unsure if the spec allows what certbot already implements . " An error message with a link to a webpage " means broken automation ( for acmetool , currently ) . 
 This is only an issue with the older revision , which is what Let 's Encrypt currently implements . The current revision of the specification has clarified matters in this regard and it is unlikely , at least for Let 's Encrypt , that the need for manual re - assent with regard to acmetool will occur again , especially after Let 's Encrypt starts supporting . So this issue has already been rectified in the specification . 
 LE does not require explicit agreement to new ToS. See the Subscriber Agreement at
Paragraph (version A):
If the server wishes to present the client with terms under which the
ACME service is to be used, it MUST indicate the URI where such terms
can be accessed in the "terms-of-service" subfield of the "meta"
field in the directory object, and the server MUST reject new-account
requests that do not have the "terms-of-service-agreed" set to
"true".
Paragraph (version B):
If the server wishes to present the client with terms under which the
ACME service is to be used, it MUST indicate the URI where such terms
can be accessed in the "terms-of-service" subfield of the "meta"
field in the directory object, and the server MUST reject new-account
requests that do not have the "terms-of-service-agreed" set to
"true".  Clients SHOULD NOT automatically agree to terms by default.
Rather, they SHOULD require some user interaction for agreement to
terms.
Paragraph (version B):
CAs using ACME to allow clients to agree to terms of service should
keep in mind that ACME clients can automate this agreement, possibly
not involving a human user.  If a CA wishes to have stronger evidence
of user consent, it may present an out-of-band requirement or
challenge to require human involvement.