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

Aaron Gable aaron at letsencrypt.org
Thu Apr 18 16:58:33 UTC 2024

On Tue, Apr 16, 2024 at 8:12 AM Wayne Thayer via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> I have three questions about the implications of changes proposed by this
> ballot:
> 1. Section 9.6.1 adds language that imposes or makes the following
> requirements explicit:
>> i. the Subscriber has been provided with the most current version of the
>> Subscriber Agreement;
>> ii. the applicable Subscriber Agreement is the Subscriber Agreement that
>> was accepted when the Certificate was issued; and
> I am aware that ACME RFC 8555 section 7.3.3 provides a mechanism for
> updating the Subscriber Agreement ("Terms of Service" in the RFC). The
> language above seems to imply that this mechanism must be used whenever a
> CA changes their Subscriber Agreement. Has this mechanism been deployed and
> used at scale?

I concur that this appears to be a new requirement, not simply a
unification of the current SA and ToS language. That's surprising, given
the ballot description and purpose.

The mechanism described in RFC 8555 Section 7.3.3 for ACME servers to
update the Subscriber Agreement is poorly designed, impractical, and is not
fully implemented by any ACME CA that I am aware of. Specifically, the
whole point of ACME is that it is automated -- operators should not need to
intervene except when they make changes to their own systems. In fact, many
ACME clients have no direct way to reach their operators (i.e. no email or
other notification facilities), they just log to a file which the operator
theoretically reads but in practice wholly ignores. So an ACME CA breaking
every single ACME client until that client's operator takes manual action
is a non-starter.

SIde note here that "accepted when the Certificate was issued" could be
> misconstrued to conflict with the statement in 9.6.3 that "a single
> Subscriber Agreement MAY be used to cover multiple future certificate
> requests and the resulting Certificates". I'd suggest changing "accepted"
> to "in force".

Agreed. Many Subscriber Agreements / Terms of Service (both across the CA
industry and other unrelated industries with similar documents) contain
language stating that they may be updated unilaterally, sometimes with
notification to the other parties, sometimes without. Making it sound like
every new version must be manually accepted seems like an unintended (and
unrealistic) consequence of the current language in this ballot.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240418/aaf29b46/attachment.html>

More information about the Servercert-wg mailing list