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", 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
