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 "...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@cabforum.org https://lists.cabforum.org/mailman/listinfo/servercert-wg
Re: [Servercert-wg] Discussion Period Begins - Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation
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. 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. 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. 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;". Thanks, Aaron ___ Servercert-wg mailing list Servercert-wg@cabforum.org https://lists.cabforum.org/mailman/listinfo/servercert-wg
Re: [Servercert-wg] Discussion Period Begins - Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation
On 18/4/2024 7:58 μ.μ., Aaron Gable via Servercert-wg wrote:
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.
I'm not sure I understand this concern. ACME clients provide a mechanism
for the Applicant to "accept" the Terms of Service or Subscriber
Agreement and signal that action to the CA. The ballot merely says that
the CA must provide their latest ToU/SA to the Applicants (this can be
done via a URL presented to the Applicant), and the Applicants must
signal their acceptance before proceeding.
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?
Thanks,
Dimitris.
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg
Re: [Servercert-wg] Discussion Period Begins - Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation
On Tue, Apr 16, 2024 at 8:12 AM Wayne Thayer via Servercert-wg <
servercert-wg@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.
Aaron
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg
Re: [Servercert-wg] Discussion Period Begins - Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation
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?
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".
2. Section 9.6.3 states that ".The CA SHALL implement a process to ensure
that ... if the CA and Subscriber are the same entity or are Affiliated,
that the Applicant has committed to comply with the Subscriber Agreement."
How would an auditor confirm this?
3. Finally, I'm wondering if some CAs could find themselves out of
compliance when these changes go into effect because they rely on Terms of
Use or need to update their Subscriber Agreement and/or CP/CPS? I don't
have a strong opinion here, but a defined effective date for these changes
might make sense.
Thanks,
Wayne
On Thu, Apr 11, 2024 at 5:49 PM Dustin Hollenback via Servercert-wg <
servercert-wg@cabforum.org> wrote:
>
>
> *Purpose of Ballot SC-071*
>
> This ballot proposes updates to the Baseline Requirements for the Issuance
> and Management of Publicly-Trusted Certificates related to Subscriber
> Agreements and Terms of Use. It combines the requirements for both into
> only the Subscriber Agreement and clarifies the requirement language. It
> removes the requirement and reference to "Terms of Use".
>
>
>
> Notes:
>
> • This removes any ambiguity to ensure that there is no
> requirement that the Subscriber Agreement be legally enforceable when the
> CA and Subscriber are affiliated.
>
> • This updates definitions for “Subscriber” and “Subscriber
> Agreement” and removes the definition for “Terms of Use” as these separate
> concepts are creating unnecessary work for CAs and Subscribers without
> adding any value when separated.
>
> • While drafting this ballot, there were concerns raised
> related to “Applicant” and “Applicant Representative”. These definitions
> were intentionally not modified in this ballot as they will require more
> discussion after we implement the change to Subscriber Agreement and
> removal of Terms of Use.
>
> • As observed with other ballots in the past, minor
> administrative updates must be made to the proposed ballot text before
> publication such that the appropriate Version # and Change History are
> accurately represented (e.g., to indicate these changes will be represented
> in Version 2.0.3).
>
> • This ballot does not modify the “Guidelines for the
> Issuance and Management of Extended Validation Certificates”. More work
> will be made to that document after changes are finalized in this one.
>
>
>
> The following motion has been proposed by Dustin Hollenback of Microsoft,
> and endorsed by Tadahiko Ito of SECOM and Ben Wilson of Mozilla.
>
>
>
> *— Motion Begins —*
>
>
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted Certificates” (“Baseline Requirements”),
> based on Version 2.0.2.
>
>
>
> MODIFY the Baseline Requirements as specified in the following Redline:
>
>
>
> Here is a link to the GitHub redline:
>
>
> https://github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031cd1bff3d4f35...1a33a904c9f7d8c9d42289f2f458358551db9f2f
>
>
>
>
> *— Motion Ends —*
>
>
>
> This ballot proposes a Final Maintenance Guideline. The procedure for
> approval of this ballot is as follows:
>
>
>
> *Discussion (7+ days)*
>
> • Start time: 2024-04-12 01:00:00 UTC
>
> • End time: 2024-04-20 01:00:00 UTC
>
>
>
> *Vote for approval (7 days)*
>
> • Start time: -XX-XX 22:00:00 UTC
>
> • End time: -XX-XX 22:00:00 UTC
>
>
>
>
>
>
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg
[Servercert-wg] Discussion Period Begins - Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation
Purpose of Ballot SC-071
This ballot proposes updates to the Baseline Requirements for the Issuance and
Management of Publicly-Trusted Certificates related to Subscriber Agreements
and Terms of Use. It combines the requirements for both into only the
Subscriber Agreement and clarifies the requirement language. It removes the
requirement and reference to "Terms of Use".
Notes:
* This removes any ambiguity to ensure that there is no
requirement that the Subscriber Agreement be legally enforceable when the CA
and Subscriber are affiliated.
* This updates definitions for "Subscriber" and "Subscriber
Agreement" and removes the definition for "Terms of Use" as these separate
concepts are creating unnecessary work for CAs and Subscribers without adding
any value when separated.
* While drafting this ballot, there were concerns raised related
to "Applicant" and "Applicant Representative". These definitions were
intentionally not modified in this ballot as they will require more discussion
after we implement the change to Subscriber Agreement and removal of Terms of
Use.
* As observed with other ballots in the past, minor administrative
updates must be made to the proposed ballot text before publication such that
the appropriate Version # and Change History are accurately represented (e.g.,
to indicate these changes will be represented in Version 2.0.3).
* This ballot does not modify the "Guidelines for the Issuance and
Management of Extended Validation Certificates". More work will be made to that
document after changes are finalized in this one.
The following motion has been proposed by Dustin Hollenback of Microsoft, and
endorsed by Tadahiko Ito of SECOM and Ben Wilson of Mozilla.
- Motion Begins -
This ballot modifies the "Baseline Requirements for the Issuance and Management
of Publicly-Trusted Certificates" ("Baseline Requirements"), based on Version
2.0.2.
MODIFY the Baseline Requirements as specified in the following Redline:
Here is a link to the GitHub redline:
https://github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031cd1bff3d4f35...1a33a904c9f7d8c9d42289f2f458358551db9f2f
- Motion Ends -
This ballot proposes a Final Maintenance Guideline. The procedure for approval
of this ballot is as follows:
Discussion (7+ days)
* Start time: 2024-04-12 01:00:00 UTC
* End time: 2024-04-20 01:00:00 UTC
Vote for approval (7 days)
* Start time: -XX-XX 22:00:00 UTC
* End time: -XX-XX 22:00:00 UTC
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg
