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

[Ben Wilson]

Dimitris, Aaron, Wayne, and Others,
We are working on improving the language of the ballot.
Here are a couple of versions for you to review and provide feedback on.
https://github.com/cabforum/servercert/commit/d0d962e04bd81a71ebf71a7c45a015cbc75ac979

https://github.com/cabforum/servercert/commit/682488a832db5b6b4fcdd4cd7cbd86ae9541453e
Thanks,
Ben


On Sun, Apr 21, 2024 at 8:29 PM Dustin Hollenback via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> Thank you all for the great feedback! We’ll take this offline and re-work
> it based on the input.
>
>
>
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf Of *Dimitris
> Zacharopoulos (HARICA) via Servercert-wg
> *Sent:* Sunday, April 21, 2024 1:24 AM
> *To:* Aaron Gable <aaron at letsencrypt.org>; CA/B Forum Server Certificate
> WG Public Discussion List <servercert-wg at cabforum.org>
> *Subject:* [EXTERNAL] Re: [Servercert-wg] Discussion Period Begins -
> Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation
>
>
>
>
>
> 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 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.
>
>
> 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 at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240423/e2d828cc/attachment.html>