Re: [Servercert-wg] [EXTERNAL] Re: Discussion Period Begins - Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation
All, I am currently looking at this version in Gitub: https://github.com/cabforum/servercert/blob/SC-71/docs/BR.md. But I'm a little confused on whether some of the recently suggested changes have been merged into that version. I'll defer to Dustin on whether Bruce's first suggestion for "Subscriber Agreement" in BR section 9.6.1 should replace the second, less preferable, option. Finally, re: the wording for the effective date, which I didn't like*, what if it said something like this instead? Prior to 2025-03-15, CAs may continue to refer to and utilize the phrase "Terms of Use" as defined in the previous version of these Requirements within their CP and CPS documents. Effective 2025-03-15, CAs shall replace references to "Terms of Use" with "Subscriber Agreement" in their CP and CPS documents. This change does not preclude the inclusion of "terms of use" and other necessary terms and conditions within broader CA operational documents, provided they are consistent with these Requirements Feel free to edit as you see fit. * My concern with the previously proposed language was that the first sentence was too broad in that it didn't specify the context in which "Terms of Use" might already be used, and similarly, my concern with the second sentence was that it was overly broad in prohibiting all uses of "Terms of Use" whatsoever. Ben On Tue, Apr 30, 2024 at 2:13 PM Bruce Morton wrote: > Hi Ben, > > > > We have some feedback from our legal team. > > > > First suggestion is to simplify the change to only address the objectives > of the ballot: > > 5. Subscriber Agreement: That, 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; > > > > Alternative (less preferable) option, accepts additional warranties that > are superfluous to the objectives of the ballot, but fixes the legal > impossibility of the last item (iii): > > 5. Subscriber Agreement: That, > > i. the Subscriber has access to the most current version of the Subscriber > Agreement, which is posted to the CA’s policy document repository or has > been provided through other means; > > ii. the applicable Subscriber Agreement is the Subscriber Agreement that > was in force when the Certificate was issued; and > > iii. 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; > > > > > > Thanks, Bruce. > > > > *From:* Servercert-wg *On Behalf Of *Ben > Wilson via Servercert-wg > *Sent:* Wednesday, April 24, 2024 3:06 AM > *To:* Wayne Thayer > *Cc:* CA/B Forum Server Certificate WG Public Discussion List < > servercert-wg@cabforum.org> > *Subject:* Re: [Servercert-wg] [EXTERNAL] Re: Discussion Period Begins - > Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation > > > > 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 > wrote: Thanks Ben!The > > 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 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 > <https://urldefense.com/v3/__https:/github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031cd1bff3d4f35...682488a832db5b6b4fcdd4cd7cbd86ae9541453e__;!!FJ-Y8qCqXTj2!c-eKDU27xX1FU55g2nJgccUKbM9SvUI7wCrdCc8dTazyEHAuWyMH8
Re: [Servercert-wg] [EXTERNAL] Re: Discussion Period Begins - Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation
Hi Ben, We have some feedback from our legal team. First suggestion is to simplify the change to only address the objectives of the ballot: 5. Subscriber Agreement: That, 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; Alternative (less preferable) option, accepts additional warranties that are superfluous to the objectives of the ballot, but fixes the legal impossibility of the last item (iii): 5. Subscriber Agreement: That, i. the Subscriber has access to the most current version of the Subscriber Agreement, which is posted to the CA’s policy document repository or has been provided through other means; ii. the applicable Subscriber Agreement is the Subscriber Agreement that was in force when the Certificate was issued; and iii. 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; Thanks, Bruce. From: Servercert-wg On Behalf Of Ben Wilson via Servercert-wg Sent: Wednesday, April 24, 2024 3:06 AM To: Wayne Thayer Cc: CA/B Forum Server Certificate WG Public Discussion List Subject: Re: [Servercert-wg] [EXTERNAL] Re: Discussion Period Begins - Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation 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 wrote: Thanks Ben!The 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 mailto: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 mailto: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<https://urldefense.com/v3/__https:/github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031cd1bff3d4f35...682488a832db5b6b4fcdd4cd7cbd86ae9541453e__;!!FJ-Y8qCqXTj2!c-eKDU27xX1FU55g2nJgccUKbM9SvUI7wCrdCc8dTazyEHAuWyMH8NRxYB1svMqXlfEAgy3PRkZE8b3FbdIFdqOVSFtXHg$> Aaron On Tue, Apr 23, 2024 at 4:25 AM Ben Wilson mailto: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://urldefense.com/v3/__https:/github.com/cabforum/servercert/commit/d0d962e04bd81a71ebf71a7c45a015cbc75ac979__;!!FJ-Y8qCqXTj2!c-eKDU27xX1FU55g2nJgccUKbM9SvUI7wCrdCc8dTazyEHAuWyMH8NRxYB1svMqXlfEAgy3PRkZE8b3FbdIFdqO29mgZfA$> https://github.com/cabforum/servercert/commit/682488a832db5b6b4fcdd4cd7cbd86ae9541453e<https://urldefense.com/v3/__https:/github.com/cabforum/servercert/commit/682488a832db5b6b4fcdd4cd7cbd86ae9541453e__;!!FJ-Y8qCqXTj2!c-eKDU27xX1FU55g2nJgccUKbM9SvUI7wCrdCc8dTazyEHAuWyMH8NRxYB1svMqXlfEAgy3PRkZE8b3FbdIFdqOn2FZUfg$> Thanks, Ben On Sun, Apr 21, 2024 at 8:29 PM Dustin Hollenback via Servercert-wg mailto: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 mailto: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 mailto:aa...@letsencrypt.org>>; CA/B Forum Server Certificate WG Public Discussion List mailto: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 mailto: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
Re: [Servercert-wg] [EXTERNAL] Re: Discussion Period Begins - Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation
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 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 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 *On Behalf >>>> Of *Dimitris Zacharopoulos (HARICA) via Servercert-wg >>>> *Sent:* Sunday, April 21, 2024 1:24 AM >>>> *To:* Aaron Gable ; CA/B Forum Server >>>> Certificate WG Public Discussion List >>>> *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 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&q
Re: [Servercert-wg] [EXTERNAL] Re: Discussion Period Begins - Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation
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 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 *On Behalf >>> Of *Dimitris Zacharopoulos (HARICA) via Servercert-wg >>> *Sent:* Sunday, April 21, 2024 1:24 AM >>> *To:* Aaron Gable ; CA/B Forum Server >>> Certificate WG Public Discussion List >>> *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 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"
Re: [Servercert-wg] [EXTERNAL] Re: Discussion Period Begins - Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation
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 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 *On Behalf Of >> *Dimitris Zacharopoulos (HARICA) via Servercert-wg >> *Sent:* Sunday, April 21, 2024 1:24 AM >> *To:* Aaron Gable ; CA/B Forum Server Certificate >> WG Public Discussion List >> *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 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 >>
Re: [Servercert-wg] [EXTERNAL] Re: Discussion Period Begins - Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation
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 *On Behalf Of > *Dimitris > Zacharopoulos (HARICA) via Servercert-wg > *Sent:* Sunday, April 21, 2024 1:24 AM > *To:* Aaron Gable ; CA/B Forum Server Certificate > WG Public Discussion List > *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 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
Re: [Servercert-wg] [EXTERNAL] Re: Discussion Period Begins - Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation
Thank you all for the great feedback! We’ll take this offline and re-work it based on the input. From: Servercert-wg On Behalf Of Dimitris Zacharopoulos (HARICA) via Servercert-wg Sent: Sunday, April 21, 2024 1:24 AM To: Aaron Gable ; CA/B Forum Server Certificate WG Public Discussion List 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 mailto: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;".
