On 19/4/2024 9:54 μ.μ., Aaron Gable wrote:
On Fri, Apr 19, 2024 at 11:07 AM Dimitris Zacharopoulos (HARICA) via
Servercert-wg <servercert-wg@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.
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 :-)
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.
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.
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?
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.
I also prefer this language but would that address the concern mentioned
above?
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;".
Great improvement indeed!
Thanks,
Dimitris.
_______________________________________________
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg
