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

Wed Apr 24 07:06:07 UTC 2024

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 <wthayer at 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 at 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 <bwilson at 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 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
>>>>
>>> _______________________________________________
>> 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/20240424/efdc685e/attachment.html>