I removed it because I didn't like the phrasing. I can propose other wording for an effective date, unless anyone else wants to take a crack at it.
On Wed, Apr 24, 2024, 1:59 AM Wayne Thayer <wtha...@gmail.com> wrote: > Thanks Ben! > > The second commit you linked removes the effective date for CP/CPS updates > from section 9.6.3. While I'm not convinced that this is necessary, it > seems to add some clarity. Was that paragraph meant to remain in place? If > not, what is the reasoning? > > Otherwise I am also happy with these changes. > > - Wayne > > On Tue, Apr 23, 2024 at 4:21 PM Aaron Gable via Servercert-wg < > servercert-wg@cabforum.org> wrote: > >> 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 >> >
_______________________________________________ Servercert-wg mailing list Servercert-wg@cabforum.org https://lists.cabforum.org/mailman/listinfo/servercert-wg
