<div dir="ltr"><div dir="ltr">On Fri, Apr 19, 2024 at 11:07 AM Dimitris Zacharopoulos (HARICA) via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
    
  
  <div>What happens if the SA/ToS document changes? I had the impression
    that the ACME client would be able to see the new version and ask
    that the updated version is accepted. How does this process work in
    practice?<br></div></blockquote><div><br></div><div>The ACME protocol itself only has one mechanism for updating the Terms of Service: respond to all requests with HTTP 403 Forbidden, error type "urn:ietf:params:acme:error:userActionRequired", and a link to a URL where a human can take action to agree to the new terms. Breaking every single ACME client until their operator takes manual action on a webpage is unacceptable and unrealistic, so ACME server operators do not actually do this.</div><div><br></div><div>However, this is preceded by one caveat: RFC 8555 Section 7.3.3 says "If the server has changed its terms of service since a client initially accepted, <i>and the server is unwilling to process a request without explicit agreement to the new terms</i>, ...".</div><div><br></div><div>So there's an easy path forward: include language in the Subscriber Agreement to the effect of "this agreement may be updated", and always be willing to process requests without explicit agreement to the new terms. At a glance, Let's Encrypt, Google Trust Services, GoDaddy, and HARICA all take this approach in their Subscriber Agreement documents.</div><div><br></div><div>So I think there are two potential issues with the proposed language:</div><div>1) "The Certificate Warranties specifically include [that]... the Subscriber has been provided with the most current version of the Subscriber Agreement" -- I think this language is <i>probably</i> fine, as long as "posted to the CA's policy document repository" counts as "provided". But I'd prefer not to have to split hairs, and so would prefer language which more clearly makes it obvious that the updated document does not have to proactively be given to each Subscriber individually and that simply posting it to the public repository is sufficient.</div><div>2) "The Certificate Warranties specifically include [that]... the applicable Subscriber Agreement is the Subscriber Agreement that was accepted when the Certificate was issued" -- Again, this language is probably technically fine, in that the Subscriber Agreement can include language saying that Subscribers are assumed to have accepted future updates to the document. But I'd still prefer not to split hairs, and so I think that Wayne's suggestion of "...that was <i>in force</i> when the Certificate was issued" is a good one.</div><div><br></div><div>Unrelated to the discussion above, our Counsel has suggested one other simplification of the language in the ballot: "if the CA and Subscriber are not Affiliated, the Subscriber and CA are parties to a legally valid and enforceable Subscriber Agreement that satisfies these Requirements, or, if the CA and Subscriber are the same entity or are Affiliated, the Applicant Representative has accepted the Subscriber Agreement;" seems unnecessarily wordy. Instead, they suggest just "the Subscriber and CA (even if they are the same entity or are Affiliated) are parties to a legally valid and enforceable Subscriber Agreement that satisfies these Requirements;".</div><div><br></div><div>Thanks,</div><div>Aaron</div></div></div>