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

Tue Apr 23 23:21:06 UTC 2024

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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240423/1dd32d79/attachment.html>