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@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-boun...@cabforum.org> *On Behalf Of > *Dimitris > Zacharopoulos (HARICA) via Servercert-wg > *Sent:* Sunday, April 21, 2024 1:24 AM > *To:* Aaron Gable <aa...@letsencrypt.org>; CA/B Forum Server Certificate > WG Public Discussion List <servercert-wg@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@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 >
_______________________________________________ Servercert-wg mailing list Servercert-wg@cabforum.org https://lists.cabforum.org/mailman/listinfo/servercert-wg
