<!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 19/4/2024 9:54 μ.μ., Aaron Gable
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAEmnErcAiw35M9ftRTHZ+qLB8VnRG02omznBehZZ3rFUSBkESg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true" class="moz-txt-link-freetext">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">
<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>
</div>
</blockquote>
<br>
The ACME protocol was designed to support popular use cases
promoting automation. The level of automation can be decided by the
Applicant. For example, if an Applicant chooses the dns-01 challenge
and wants to manually update their DNS server to include the
challenge, so be it. That doesn't mean that this breaks every single
ACME client. It's supposed to be a feature, not a bug :-)<br>
<br>
My point is that if an Applicant wants to automate the response to a
new Terms of Service, they can program the ACME client to connect to
the return URL with the new document, accept it and continue with
the request.<br>
<br>
<blockquote type="cite"
cite="mid:CAEmnErcAiw35M9ftRTHZ+qLB8VnRG02omznBehZZ3rFUSBkESg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
</div>
</blockquote>
<br>
In some cases, CAs point to a URL that contains the latest version
of the Subscriber Agreement, so in one sense the Applicant agrees to
that -latest- version without the need to see a different URL. The
only concern here is what happens to implementations where the
Applicant accepts the Subscriber Agreement at account creation and
not at Certificate Issuance/Retrieval. In that scenario, the CA
would not be able to claim that the Applicant has accepted the
updated version, right?<br>
<br>
<blockquote type="cite"
cite="mid:CAEmnErcAiw35M9ftRTHZ+qLB8VnRG02omznBehZZ3rFUSBkESg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
</div>
</blockquote>
<br>
I also prefer this language but would that address the concern
mentioned above?<br>
<br>
<blockquote type="cite"
cite="mid:CAEmnErcAiw35M9ftRTHZ+qLB8VnRG02omznBehZZ3rFUSBkESg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
</div>
</blockquote>
<br>
Great improvement indeed!<br>
<br>
Thanks,<br>
Dimitris.<br>
</body>
</html>