Hi Ben, Thank you! I believe those combine with the previous commits to produce this redline, which looks good to me: https://github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031cd1bff3d4f35...682488a832db5b6b4fcdd4cd7cbd86ae9541453e
Aaron On Tue, Apr 23, 2024 at 4:25 AM Ben Wilson <bwil...@mozilla.com> wrote: > 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
