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

[Dustin Hollenback via Servercert-wg]

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 mailto:servercert-wg@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 mail

[Servercert-wg] Pre-ballot SC-74 - Clarify CP/CPS structure according to RFC 3647

[Dimitris Zacharopoulos (HARICA) via Servercert-wg]

Dear Members,

Following up to the CP/CPS RFC3647 alignment discussion at the last F2F, 
I prepared a ballot to address the ambiguity regarding the appropriate 
sections from RFC 3647 that CAs need to include in their CP and/or CPS 
documents.


An effective date was added because these changes may be considered 
normative compared to the current version of the BRs. I also included 
elements from section 3.3(5) of MRSP 
.


Please let me know if you have any comments or concerns. I also need one 
more endorser to kick off the official discussion period.



Best regards,
Dimitris.


 SC-74 - Clarify CP/CPS structure according to RFC 3647


   Summary

The TLS Baseline Requirements require in section 2.2 that:

/"The Certificate Policy and/or Certification Practice Statement MUST be 
structured in accordance with RFC 3647 and MUST include all material 
required by RFC 3647."/


The intent of this language was to ensure that all CAs' CP and/or CPS 
documents contain a similar structure, making it easier to review and 
compare against the BRs. However, there was some ambiguity as to the 
actual structure that CAs should follow. After several discussions in 
the SCWG Public Mailing List 
 
and F2F meetings, it was agreed that more clarity should be added to the 
existing requirement, pointing to the outline described in section 6 of 
RFC 3647.


The following motion has been proposed by Dimitris Zacharopoulos 
(HARICA) and endorsed by Aaron Poulsen (Amazon) and  ().


You can view and comment on the github pull request representing this 
ballot here .



   Motion Begins

MODIFY the "Baseline Requirements for the Issuance and Management of 
Publicly-Trusted TLS Server Certificates" based on Version 2.0.4 as 
specified in the following redline:


 * https://github.com/cabforum/servercert/pull/503/files (EDITORIAL
   NOTE: this link will be replaced with the immutable URL before
   starting the official discussion period)


   Motion Ends

This ballot proposes a Final Maintenance Guideline. The procedure for 
approval of this ballot is as follows:



   Discussion (at least 7 days)

 * Start time: 2024-04-29 10:00:00 UTC
 * End time: on or after 2024-05-06 10:00:00 UTC


   Vote for approval (7 days)

 * Start time: TBD
 * End time: TBD

___
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 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

[Servercert-wg] Weekly github digest (Server Certificate Working Group)

[Infrastructure Bot via Servercert-wg]

Issues
--
* cabforum/servercert (+2/-0/💬5)
 2 issues created:
 - Remove extraneous "for either" in 3.2.2.4.7 (by clintwilson)
   https://github.com/cabforum/servercert/issues/502 [baseline-requirements] [clean-up] 
 - Review of EVG cabfOrganizationIdentifier  (by srdavidson)
   https://github.com/cabforum/servercert/issues/499 [ev-guidelines] 


 2 issues received 5 new comments:
 - #499 Review of EVG cabfOrganizationIdentifier  (4 by CBonnell, clintwilson, 
srdavidson)
   https://github.com/cabforum/servercert/issues/499 [ev-guidelines] [validation-sc] 
 - #354 Permit the inclusion of LEIs in Subject fields (1 by srdavidson)
   https://github.com/cabforum/servercert/issues/354 [validation-sc] 




Pull requests
-
* cabforum/servercert (+2/-2/💬0)
 2 pull requests submitted:
 - Ballot SC-XX: Modify section 3.2.2.4.7 to allow CA Assisted DNS Valid… (by 
slghtr-says)
   https://github.com/cabforum/servercert/pull/501 
 - Ballot SC-073: Compromised and Weak Keys (by wthayer)
   https://github.com/cabforum/servercert/pull/500 


 2 pull requests merged:
 - SC65: Convert EVGs into RFC 3647 format v2 (#440)
   https://github.com/cabforum/servercert/pull/493 
 - Ballot SC-69: Clarify router and firewall logging requirements (#477)
   https://github.com/cabforum/servercert/pull/491 



Repositories tracked by this digest:
---
* https://github.com/cabforum/servercert
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg