<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 18/4/2024 7:58 μ.μ., Aaron Gable via
Servercert-wg wrote:<br>
</div>
<blockquote type="cite"
cite="mid:0100018ef225a8e1-ddc3ffc6-5ab0-4137-8d2e-1c2e127b1cc1-000000@email.amazonses.com">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div><br>
</div>
<div>1. Section 9.6.1 adds language that imposes or makes the
following requirements explicit:</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">i.
the Subscriber has been provided with the most current
version of the Subscriber Agreement;<br>
ii. the applicable Subscriber Agreement is the Subscriber
Agreement that was accepted when the Certificate was issued;
and</blockquote>
<div><br>
</div>
<div>I am aware that ACME RFC 8555 section 7.3.3 provides a
mechanism for updating the Subscriber Agreement ("Terms of
Service" in the RFC). The language above seems to imply that
this mechanism must be used whenever a CA changes their
Subscriber Agreement. Has this mechanism been deployed and
used at scale?</div>
</div>
</blockquote>
<div><br>
</div>
<div>I concur that this appears to be a new requirement, not
simply a unification of the current SA and ToS language. That's
surprising, given the ballot description and purpose.</div>
<div><br>
</div>
<div>The mechanism described in RFC 8555 Section 7.3.3 for ACME
servers to update the Subscriber Agreement is poorly designed,
impractical, and is not fully implemented by any ACME CA that I
am aware of. Specifically, the whole point of ACME is that it is
automated -- operators should not need to intervene except when
they make changes to their own systems. In fact, many ACME
clients have no direct way to reach their operators (i.e. no
email or other notification facilities), they just log to a file
which the operator theoretically reads but in practice wholly
ignores. So an ACME CA breaking every single ACME client until
that client's operator takes manual action is a non-starter.</div>
</blockquote>
<br>
I'm not sure I understand this concern. ACME clients provide a
mechanism for the Applicant to "accept" the Terms of Service or
Subscriber Agreement and signal that action to the CA. The ballot
merely says that the CA must provide their latest ToU/SA to the
Applicants (this can be done via a URL presented to the Applicant),
and the Applicants must signal their acceptance before proceeding.<br>
<br>
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>
<br>
<br>
Thanks,<br>
Dimitris.<br>
</body>
</html>