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

[Aaron Gable via Servercert-wg]

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

[Dimitris Zacharopoulos (HARICA) via Servercert-wg]

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] Notice of review period: Ballot SC65: Convert EVGs into RFC 3647 format

[Inigo Barreira via Servercert-wg]

This is to notify the community that the IPR review period for ballot SC65
(Convert EVGs into RFC 3647 format) has completed. No IPR Exclusion Notices
were filed, and the ballot becomes effective as of 19 April 2024.

 

The TLS Baseline Requirements version 2.0.4 and the EVGs version 2.0.0 have
been published to the CABF
 public website in accordance with the Bylaws.

 

Regards

 

 

De: Servercert-wg  En nombre de Inigo
Barreira via Servercert-wg
Enviado el: viernes, 15 de marzo de 2024 11:01
Para: CA/B Forum Server Certificate WG Public Discussion List

Asunto: [Servercert-wg] Notice of review period: Ballot SC65: Convert EVGs
into RFC 3647 format

 

CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you recognize the sender and know the
content is safe.

 

 

NOTICE OF REVIEW PERIOD

This Review Notice is sent pursuant to Section 4.1 of the CA/Browser Forum’s
Intellectual Property Rights Policy (v1.3). This Review Period of 30 days is
for two Final Maintenance Guidelines. The complete Draft Maintenance
Guideline that is the subject of this Review Notice is attached to this
email, both in red-line and changes-accepted draft format, in Word and PDF
versions.

 

Summary of Review

Ballot for Review: Ballot SC65: Convert EVGs into RFC 3647 format

 

Start of Review Period: 15 March 2024 at 10:00 UTC

End of Review Period: 15 April 2024 at 10:00 UTC

 

Members with any Essential Claim(s) to exclude must forward a written Notice
to Exclude Essential Claims to the Working Group Chair (email to Iñigo
Barreira mailto:inigo.barre...@sectigo.com> >)
and also submit a copy to the CA/B Forum public mailing list (email to
public at cabforum.org<  mailto:public at
cabforum.org>) before the end of the Review Period.

For details, please see the current version of the

CA/Browser Forum Intellectual Property Rights Policy.

(An optional template for submitting an Exclusion Notice is available at

https://cabforum.org/wp-content/uploads/Template-for-Exclusion-Notice.pdf)

 



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg