[Servercert-wg] Discussion Period Begins - Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation

[Aaron Gable]

On Fri, Apr 19, 2024 at 11:07 AM Dimitris Zacharopoulos (HARICA) via
Servercert-wg <servercert-wg at cabforum.org> wrote:

> 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?
>

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.

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, *and the server is unwilling to process a request
without explicit agreement to the new terms*, ...".

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.

So I think there are two potential issues with the proposed language:
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 *probably* 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.
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 *in force* when the
Certificate was issued" is a good one.

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;".

Thanks,
Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240419/85d3f7eb/attachment.html>