Re: [Servercert-wg] [Voting Begins] Ballot SC-74 - Clarify CP/CPS structure according to RFC 3647

[Ben Wilson via Servercert-wg]

Mozilla changes its vote to "no" on Ballot SC-74 with the understanding
that additional edits are needed.

On Sun, May 5, 2024 at 1:05 PM Ben Wilson  wrote:

> Mozilla votes "yes" on Ballot SC-74.
>
> On Sun, May 5, 2024 at 3:06 AM Dimitris Zacharopoulos (HARICA) via
> Servercert-wg  wrote:
>
>> HARICA votes "yes" to ballot SC-74.
>>
>> On 5/5/2024 11:24 π.μ., Dimitris Zacharopoulos (HARICA) via Servercert-wg
>> wrote:
>>
>> Voting begins for ballot SC-74.
>> 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 Tim Hollebeek (Digicert).
>>
>> You can view 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/compare/c4a34fe2292022e0a04ba66b5a85df75907ac2a2...f6a90e2a652fbb7a2d62a976b70f4af3adce8dae
>>
>> 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-25 16:30:00 UTC
>>- End time: on or after 2024-05-02 16:30:00 UTC
>>
>> Vote for approval (7 days)
>>
>>- Start time: 2024-05-05 8:30:00 UTC
>>- End time: 2024-05-12 8:30:00 UTC
>>
>>
>>
>> ___
>> Servercert-wg mailing 
>> listServercert-wg@cabforum.orghttps://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 mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] [Voting Begins] Ballot SC-74 - Clarify CP/CPS structure according to RFC 3647

[Ben Wilson via Servercert-wg]

Mozilla votes "yes" on Ballot SC-74.

On Sun, May 5, 2024 at 3:06 AM Dimitris Zacharopoulos (HARICA) via
Servercert-wg  wrote:

> HARICA votes "yes" to ballot SC-74.
>
> On 5/5/2024 11:24 π.μ., Dimitris Zacharopoulos (HARICA) via Servercert-wg
> wrote:
>
> Voting begins for ballot SC-74.
> 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 Tim Hollebeek (Digicert).
>
> You can view 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/compare/c4a34fe2292022e0a04ba66b5a85df75907ac2a2...f6a90e2a652fbb7a2d62a976b70f4af3adce8dae
>
> 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-25 16:30:00 UTC
>- End time: on or after 2024-05-02 16:30:00 UTC
>
> Vote for approval (7 days)
>
>- Start time: 2024-05-05 8:30:00 UTC
>- End time: 2024-05-12 8:30:00 UTC
>
>
>
> ___
> Servercert-wg mailing 
> listServercert-wg@cabforum.orghttps://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 mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Ben Wilson via Servercert-wg]

All,

I am currently looking at this version in Gitub:
https://github.com/cabforum/servercert/blob/SC-71/docs/BR.md. But I'm a
little confused on whether some of the recently suggested changes have been
merged into that version.

I'll defer to Dustin on whether Bruce's first suggestion for "Subscriber
Agreement" in BR section 9.6.1 should replace the second, less preferable,
option.

Finally, re: the wording for the effective date, which I didn't like*, what
if it said something like this instead?

Prior to 2025-03-15, CAs may continue to refer to and utilize the phrase
"Terms of Use" as defined in the previous version of these Requirements
within their CP and CPS documents. Effective 2025-03-15, CAs shall replace
references to "Terms of Use" with "Subscriber Agreement" in their CP and
CPS documents. This change does not preclude the inclusion of "terms of
use" and other necessary terms and conditions within broader CA operational
documents, provided they are consistent with these Requirements

Feel free to edit as you see fit.

* My concern with the previously proposed language was that the first
sentence was too broad in that it didn't specify the context in which
"Terms of Use" might already be used, and similarly, my concern with the
second sentence was that it was overly broad in prohibiting all uses of
"Terms of Use" whatsoever.

Ben

On Tue, Apr 30, 2024 at 2:13 PM Bruce Morton 
wrote:

> Hi Ben,
>
>
>
> We have some feedback from our legal team.
>
>
>
> First suggestion is to simplify the change to only address the objectives
> of the ballot:
>
> 5. Subscriber Agreement: That, 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;
>
>
>
> Alternative (less preferable) option, accepts additional warranties that
> are superfluous to the objectives of the ballot, but fixes the legal
> impossibility of the last item (iii):
>
> 5. Subscriber Agreement: That,
>
> i. the Subscriber has access to the most current version of the Subscriber
> Agreement, which is posted to the CA’s policy document repository or has
> been provided through other means;
>
> ii. the applicable Subscriber Agreement is the Subscriber Agreement that
> was in force when the Certificate was issued; and
>
> iii. 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;
>
>
>
>
>
> Thanks, Bruce.
>
>
>
> *From:* Servercert-wg  *On Behalf Of *Ben
> Wilson via Servercert-wg
> *Sent:* Wednesday, April 24, 2024 3:06 AM
> *To:* Wayne Thayer 
> *Cc:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg@cabforum.org>
> *Subject:* Re: [Servercert-wg] [EXTERNAL] Re: Discussion Period Begins -
> Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation
>
>
>
> 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
>
> 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
> <https://urldefense.com/v3/__https:/github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031cd1bff3d4f35...682488a832db5b6b4fcdd4cd7cbd86ae9541453e__;!!FJ-Y8qCqXTj2!c-eKDU27xX1FU55g2nJgccUKbM9SvUI7wCrdCc8dTazyEHAuWyMH8

Re: [Servercert-wg] Voting Period Begins - Ballot SC-073: Compromised and Weak Keys

[Ben Wilson via Servercert-wg]

Mozilla votes "yes".

On Fri, Apr 26, 2024 at 2:00 AM Wayne Thayer via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> Purpose of Ballot SC-073
>
> This ballot proposes updates to the Baseline Requirements for the Issuance
> and Management of Publicly-Trusted TLS Server Certificates related to weak
> and compromised private keys. These changes lie primarily in Section
> 6.1.1.3:
>
>-
>
>6.1.1.3(4) clarifies that, for the purpose of this requirement, CAs
>shall be made aware of compromised keys using their existing notification
>mechanism(s).
>-
>
>6.1.1.3(5) improves guidance for CAs around the detection of weak
>keys. Should this ballot pass, these changes become effective on November
>15, 2024.
>
> Notes:
>
>-
>
>This ballot builds on the extensive work done by SSL.com in creating
>ballot SC-59v2 Weak Key Guidance. SSL.com’s contributions are appreciated.
>-
>
>Thanks to Rob Stradling of Sectigo for the generation and publication
>of the set of Debian weak keys referenced in this ballot.
>-
>
>The Debian weak keys requirements have been discussed extensively,
>including in the following threads:
>https://lists.cabforum.org/pipermail/servercert-wg/2024-March/004291.html
>and
>https://lists.cabforum.org/pipermail/servercert-wg/2024-April/004422.html
>
>-
>
>This ballot does not appear to conflict with any other ballots that
>are currently under discussion.
>
>
> The following motion has been proposed by Wayne Thayer of Fastly, and
> endorsed by Brittany Randall of GoDaddy and Bruce Morton of Entrust.
>
> — Motion Begins —
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted Certificates” (“Baseline Requirements”),
> based on Version 2.0.3.
>
> MODIFY the Baseline Requirements for the Issuance and Management of
> Publicly-Trusted TLS Server Certificates as specified in the following
> Redline:
>
> Here is a link to the immutable GitHub redline:
> https://github.com/cabforum/servercert/compare/a65402cff89affe1fc0a1f0e49807c7e42e1608a...bee10c8e4a56815bffd59fab12cbd4044baa7cc0
>
>
> — 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-18 00:00:00 UTC
>-
>
>End time: 2024-04-26 00:00:00 UTC
>
> Vote for approval (7 days)
>
>-
>
>Start time: 2024-04-26 00:00:00 UTC
>- End time: 2024-05-03 00: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

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

[Ben Wilson via Servercert-wg]

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 

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

[Ben Wilson via Servercert-wg]

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

Re: [Servercert-wg] Notice of review period: Ballot SC70: Clarify the use of DTPs for Domain Control Validation

[Ben Wilson via Servercert-wg]

All,
I would like to help start up the patent advisory group. If you are
interested in participating or having your IP counsel involved, please
email me directly.
Thanks,
Ben

On Tue, Mar 26, 2024 at 3:32 AM Inigo Barreira via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> During the review period one member has filled an exclusion notice and
> according to article 2.4, point 9 of the bylaws, the results of the initial
> vote are rescinded and deemed null and void.
>
> A Patent Advisory Group (PAG) will be formed, in accordance with Section
> 7 of the IPR Policy, to address the conflict.
>
>
>
> *De:* Servercert-wg  *En nombre de *Inigo
> Barreira via Servercert-wg
> *Enviado el:* viernes, 23 de febrero de 2024 19:06
> *Para:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg@cabforum.org>
> *Asunto:* [Servercert-wg] Notice of review period: Ballot SC70: Clarify
> the use of DTPs for Domain Control Validation
>
>
>
> 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 one 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 SC70: Clarify the use of DTPs for Domain
> Control Validation
>
>
>
> *Start of Review Period: 23 February 2024 at 18:00 UTC*
>
> *End of Review Period: 23 March 2024 at 18: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 ) and also submit a copy to
> the CA/B Forum public mailing list (email to public at 
> cabforum.org 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
> 
> )
>
>
> ___
> 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

Re: [Servercert-wg] Ballot to introduce linting in the TLS BRs

[Ben Wilson via Servercert-wg]

Hi Dimitris,
You can add me.
Thanks,
Ben

On Tue, Mar 19, 2024 at 9:01 AM Dimitris Zacharopoulos (HARICA) via
Servercert-wg  wrote:

>
>
> On 19/3/2024 5:27 π.μ., Corey Bonnell wrote:
>
> Hi Dimitris,
>
> I’d be happy to endorse and help flesh out the language.
>
>
> Thank you Corey, I added your name on the table with future ballots. Is
> there anyone else?
>
>
> Best regards,
> Dimitris.
>
>
>
> Thanks,
>
> Corey
>
>
>
> *From:* Servercert-wg 
>  *On Behalf Of *Dimitris
> Zacharopoulos (HARICA) via Servercert-wg
> *Sent:* Sunday, March 17, 2024 8:20 AM
> *To:* CA/B Forum Server Certificate WG Public Discussion List
>  
> *Subject:* [Servercert-wg] Ballot to introduce linting in the TLS BRs
>
>
>
> Hi all,
>
> This is still very draft
> 
> based on the latest F2F. I would like to ask for 2 endorsers so we can work
> on the details of the ballot language in the next few of weeks.
>
>
> Thank you,
> Dimitris.
>
>
> ___
> 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

Re: [Servercert-wg] Discussion Period Begins - Ballot SC-067 V1: "Require domain validation and CAA checks to be performed from multiple Network Perspectives”

[Ben Wilson via Servercert-wg]

Greetings Antti,
Somehow, our group (working on the Subscriber Agreement/Terms of Use
ballot) had selected ballot number 67 on the wiki, but there were two
different wiki pages with ballot numbers that people were unaware of (which
led to a second selection of #67 by Chris and Ryan).  So Dustin, Tadahiko,
and I decided to go with SC-071 (the next unallocated one) for our ballot.
Ben

On Mon, Mar 18, 2024 at 11:19 PM Backman, Antti via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> Hi Chris
>
>
>
> Could there be a numbering clash with this ballot and the one being worked
> on by Ben Wilson?
>
>
>
> “[Servercert-wg] Draft Ballot SC-067: Applicant, Subscriber and Subscriber
> Agreements - Feedback r”
>
> As I am not completely sure how ballot numbering should work out, can the
> numbers be recycled or how that pans out?
>
>
>
>
>
>
>
> //Antti
>
>
>
> *From: *Servercert-wg  on behalf of
> Chris Clements via Servercert-wg 
> *Date: *Monday, 18. March 2024 at 17.32
> *To: *CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg@cabforum.org>
> *Subject: *[Servercert-wg] Discussion Period Begins - Ballot SC-067 V1:
> "Require domain validation and CAA checks to be performed from multiple
> Network Perspectives”
>
> *Purpose of Ballot SC-067*:
>
>
>
> This Ballot proposes updates to the *Baseline Requirements for the
> Issuance and Management of Publicly-Trusted TLS Server Certificates*
> (i.e., TLS BRs) related to “Multi-Perspective Issuance Corroboration”
> (“MPIC”).
>
>
>
> *Background*:
>
>
>
> - MPIC refers to performing domain validation and CAA checks from multiple
> Network Perspectives before certificate issuance, as described within the
> Ballot for the applicable validation methods in TLS BR Sections 3.2.2.4 and
> 3.2.2.5.
>
> - Not all methods described in TLS BR Sections 3.2.2.4 and 3.2.2.5 will
> require using MPIC.
>
> - This work was most recently motivated by research presented at
> Face-to-Face 58 [1] by Princeton University, but has been discussed for
> years prior as well.
>
> - The goal of this proposal is to make it more difficult for adversaries
> to successfully launch equally-specific prefix attacks against the domain
> validation processes described in the TLS BRs.
>
> - Additional background information can be found in an update shared at
> Face-to-Face 60 [2].
>
>
>
> *Benefits of Adoption*:
>
>
>
> - Recent publicly-documented attacks have used BGP hijacks to fool domain
> control validation and obtain malicious certificates, which led to the
> impersonation of HTTPS websites [3][4].
>
> - Routing security defenses (e.g., RPKI) can mitigate the risk of global
> BGP attacks, but localized, equally-specific BGP attacks still pose a
> significant threat to the Web PKI [5][6].
>
> - Corroborating domain control validation checks from multiple network
> perspectives (i.e., MPIC) spread across the Internet substantially reduces
> the threat posed by equally-specific BGP attacks, ensuring the integrity of
> domain validation and issuance decisions [5][7][8].
>
> - Existing deployments of MPIC at the scale of millions of certificates a
> day demonstrate the feasibility of this technique at Internet scale [7][9].
>
>
>
> *Intellectual Property (IP) Disclosure*:
>
>
>
> - While not a Server Certificate Working Group Member, researchers from
> Princeton University presented at Face-to-Face 58, provided academic
> expertise, and highlighted publicly-available peer-reviewed research to
> support Members in drafting this ballot.
>
> - The Princeton University researchers indicate that they have not filed
> for any patents relating to their MPIC work and do not plan to do so in the
> future.
>
> - Princeton University has indicated that it is unable to agree to the
> CA/Browser Forum IPR agreement because it could encumber inventions
> invented by researchers not involved in the development of MPIC or with the
> CA/B Forum.
>
> - Princeton University has instead provided the attached IPR statement.
> Pursuant to the IPR statement, Princeton University has granted a worldwide
> royalty free license to the intellectual property in MPIC developed by the
> researchers and has made representations regarding its lack of knowledge of
> any other Princeton intellectual property needed to implement MPIC.
>
> - For clarity, Princeton University’s IPR statement is NOT intended to
> replace the Forum’s IPR agreement or allow Princeton to participate in the
> Forum in any capacity.
>
> - Members seeking legal advice regarding this ballot should consult their
> own counsel.
>
>
>
> *Proposal Revision History*:
>
>
>
> - Pre-Ballot Release #1 (work team artifacts and broader Validation
> Subcommittee collaboration) [10]
>
> - Pre-Ballot Release #2 [11]
>
>
>
> *Previous versions of this Ballot*:
>
>
>
> - N/A, this is the first discussion period.
>
>
>
> *References*:
>
> [1]
> https://cabforum.org/wp-content/uploads/13-CAB-Forum-face-to-face-multiple-vantage-points.pdf
>
> [2]
> 

Re: [Servercert-wg] [Voting Period Begins]: SC65: Convert EVGs into RFC 3647 format v2

[Ben Wilson via Servercert-wg]

Mozilla votes "yes" on Ballot SC-65 - Convert EVGs to RFC 3647 format

On Mon, Mar 4, 2024 at 8:33 AM Inigo Barreira via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> *Summary: *
>
> The Extended Validation Certificates guidelines (EVGs) were developed and
> written in a specific format. Since then, the RFC 3647 has been the basis
> (and the de-facto standard) for the CA/Browser Forum to develop other
> documents.
>
> This ballot aims to update the EVGs to follow the RFC 3647 format without
> changing any content, just moving current sections to those defined in the
> RFC 3647. There are no normative requirements changes.
>
> This change also affects the Baseline Requirements for TSL certificates
> (BRs) which needs to point to the new sections of the EVGs. Both documents
> will be updated according to the latest version published.
>
> This ballot is proposed by Iñigo Barreira (Sectigo) and endorsed by Pedro
> Fuentes (OISTE) and Ben Wilson (Mozilla).
>
> --- Motion Begins ---
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted TLS Certificates" ("TLS Baseline
> Requirements"), based on Version 2.0.2 and the “Guidelines for the Issuance
> and Management of Extended Validation Certificates” (EVGs) based on Version
> 1.8.0.
>
> MODIFY the TLS EVGs and BRs as specified in the following Redline:
>
> Comparing
> 90a98dc7c1131eaab01af411968aa7330d315b9b...dedeebfe036fa5a6f0d7ae985ea08317ba60b8cb
> · cabforum/servercert (github.com)
> 
>
> --- Motion Ends ---
>
> This ballot proposes a Final Maintenance Guideline for the BRs and EVGs.
> The procedure for approval of this ballot is as follows:
>
> Discussion (at least 7 days)
>
>1. Start time: 2024-02-20 17:00:00 UTC
>2. End time: not before 2024-03-04 15:00:00 UTC
>
> Vote for approval (7 days)
>
>1. Start time: 2024-03-04 15:30:00 UTC
>2. End time: 2024-03-11 15:30: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

Re: [Servercert-wg] [Voting Period Begins]: SC-69v3 Clarify router and firewall logging requirements

[Ben Wilson via Servercert-wg]

Mozilla votes "yes" on Ballot SC-69v3 - Clarify router and firewall logging
requirements.

On Mon, Mar 4, 2024 at 3:59 AM Martijn Katerbarg via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> *Summary: *
>
> This ballot aims to clarify what data needs to be logged as part of the
> "Firewall and router activities" logging requirement in the Baseline
> Requirements.
>
> This ballot is proposed by Martijn Katerbarg (Sectigo) and endorsed by
> Daniel Jeffery (Fastly) and Ben Wilson (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:
> https://github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031cd1bff3d4f35...d5bd141e14de098ff00c10de7cf500668cbc6843
> 
>
> --- Motion Ends ---
>
> This ballot proposes a Final Maintenance Guideline. The procedure for
> approval of this ballot is as follows:
>
> Discussion (at least 7 days)
>
>1. Start time: 2024-02-26 07:00:00 UTC
>2. End time: 2024-03-04 11:00:00 UTC
>
> Vote for approval (7 days)
>
>1. Start time: 2024-03-04 11:00:00 UTC
>2. End time: 2024-03-11 11: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

Re: [Servercert-wg] [Voting Period Begins] SC-070: Clarify the use of DTPs for Domain Control Validation

[Ben Wilson via Servercert-wg]

Mozilla votes "yes" to Ballot SC-070.

On Tue, Feb 13, 2024 at 9:56 AM Aaron Gable via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> This new voting period is to fix a typo in the End timestamp of the voting
> period for the previous version of this ballot. The contents of the motion
> itself are identical. My apologies for the confusion.
>
> This ballot aims to clarify the existing language around the use of
> delegated third-parties during domain and IP address control validation. It
> leaves the existing language in place, and adds specifics for the cases of
> DNS queries, WHOIS lookups, and contact with the Domain Name Registrat or
> IP Address Registration Authority.
>
> Additionally, it places these same restrictions on CAA checking, with an
> effective date of 2024-05-15.
>
> This ballot is proposed by Aaron Gable (ISRG / Let's Encrypt) and endorsed
> by Mads Henriksveen (Buypass) and Dimitris Zacharopoulos (HARICA). You can
> view and comment on the github pull request representing this ballot here:
> https://github.com/cabforum/servercert/puhttps://lists.cabforum.org/pipermail/servercert-wg/2024-February/004174.htmlll/475
> 
>
> The preceding discussion can be seen here:
> https://lists.cabforum.org/pipermail/servercert-wg/2024-February/004174.html
>
> --- 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:
> https://github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031cd1bff3d4f35...00ea6e24c474fd0ab6eecc25cb8eb733fffc60c3
>
> --- Motion Ends ---
>
> Discussion (at least 7 days):
> - Start: 2024-02-02 22:30 UTC
> - End: 2024-02-12 22:30 UTC
>
> Vote for approval (7 days):
> - Start: 2024-02-13 17:00 UTC
> - End: 2024-02-20 17:00 UTC
>
> Thanks,
> Aaron
> ___
> 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

Re: [Servercert-wg] Seeking endorsers: SC-065: Convert EVGs into RFC 3647 format pre-ballot

[Ben Wilson via Servercert-wg]

I'm willing to endorse.

On Thu, Feb 8, 2024 at 10:52 AM Inigo Barreira via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> Hi,
>
>
>
> As mentioned in the past SCWG call, I´m looking for 2 endorsers for this
> ballot.
>
>
>
> Regards
>
>
>
> *De:* Servercert-wg  *En nombre de *Inigo
> Barreira via Servercert-wg
> *Enviado el:* viernes, 19 de enero de 2024 13:28
> *Para:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg@cabforum.org>; Dimitris Zacharopoulos (HARICA) <
> dzach...@harica.gr>; Bruce Morton ; Tim
> Hollebeek 
> *Asunto:* Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format
> pre-ballot
>
>
>
> 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.
>
>
>
> Hi all,
>
>
>
> As per yesterday´s SCWG call, I´ve also updated the BRs with the new
> section numbers of the EVG. Only 2 sections have been affected and
> therefore updated.
>
> Section 3.2.2.4.7
>
> EVG 11.14.3 à 3.2.2.14.3
>
>
>
> Section 7.1.2.7.5
>
> EVG 9.2 à 7.1.4.2
>
>
>
> You can find all the information in the PR 440, EVGs based on RFC3647 by
> barrini · Pull Request #440 · cabforum/servercert (github.com)
> 
>
> First, I had to update the current version of the BRs I was working with
> (2.0.0) to the current one (2.0.2) and then make the changes to the newest
> one.
>
>
>
> Regards
>
>
>
> *De:* Inigo Barreira 
> *Enviado el:* viernes, 15 de diciembre de 2023 12:42
> *Para:* Inigo Barreira ; CA/B Forum Server
> Certificate WG Public Discussion List ;
> Dimitris Zacharopoulos (HARICA) ; Bruce Morton <
> bruce.mor...@entrust.com>; Tim Hollebeek 
> *Asunto:* RE: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format
> pre-ballot
>
>
>
> Hi everyone
>
>
>
> As per last week discussion during the SCWG, we agreed to follow section 6
> of the RFC 3647 for the new EVG format.
>
> With that in mind, I´ve updated the correspondent PR (#440) to reflect it
> that way, so:
>
>- Changed section 1.1 name from scope to overview
>- Created a new section 3.2.1 for possession of the private key
>- Moved all the other stuff of the old section 11 to a “new” section
>3.2.2 for organization identity.
>- Also created the remaining ones, 3.2.3, 3.2.4, etc.
>- Update section 8 removing section 8.1 and renumbering the others and
>putting the self audits under 8.1 and leaving section 8.7 for readiness
>audits because don´t know where it can fit better (this section does not
>exist in RFC 3647 section 6)
>- Checked all links
>
>
>
> In any case, see the comparison here: Comparing
> 90a98dc7c1131eaab01af411968aa7330d315b9b...238ff99fbe04f2aa24f2c58910d8133f2283f11e
> · cabforum/servercert (github.com)
> 
>
>
>
> If you´re ok with this change, we can move forward a propose the ballot
> for which I´ll need 2 endorsers.
>
>
>
> Regards
>
>
>
> *De:* Servercert-wg  *En nombre de *Inigo
> Barreira via Servercert-wg
> *Enviado el:* jueves, 7 de diciembre de 2023 13:08
> *Para:* Dimitris Zacharopoulos (HARICA) ; Bruce
> Morton ; CA/B Forum Server Certificate WG
> Public Discussion List ; Tim Hollebeek <
> tim.holleb...@digicert.com>
> *Asunto:* Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format
> pre-ballot
>
>
>
> 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.
>
>
>
> Hi there,
>
>
>
> See the comparing one.
>
> Comparing
> 90a98dc7c1131eaab01af411968aa7330d315b9b...13b4f85a494fefa52510512a2fb3c4d7c77a7a36
> · cabforum/servercert (github.com)
> 

Re: [Servercert-wg] Voting Begins for Ballot SC-68: Allow VATEL and VATXI for organizationIdentifier

[Ben Wilson via Servercert-wg]

Mozilla votes "Yes" to Ballot SC-68.

On Tue, Jan 23, 2024 at 2:00 AM Dimitris Zacharopoulos (HARICA) via
Servercert-wg  wrote:

> This email initiates the voting period for ballot SC-68. Please vote.
>
>
> Purpose of the Ballot
>
> The EV Guidelines have strict rules in the organizationIdentifier values
> and require the country code of all currently-allowed Registration Schemes
> (NTR, VAT, PSD) to follow the ISO 3166-1 for the 2-letter country prefix.
>
> The organizationIdentifier language mainly came from ETSI EN 319 412-1 and
> then the SCWG made several modifications. However, there is an exception
> for Greece specifically for the VAT Registration Scheme that is aligned
> with Article 215 of Council Directive 2006/112/EC
>  that allows Greece to use
> the country prefix "EL". In practice, Greece uses the prefix "EL" to
> identify itself next to the VAT number of all Legal Entities
> registered/incorporated/established in Greece, and all other European
> Countries use this prefix to identify Greek VAT numbers. This can easily be
> verified in the VIES VAT number validation website
>  where
> Greece is listed as"EL".
>
> There is also Council Directive 2020/1756
>  amending Directive
> 2006/112/EC that requires the prefix "XI" for the identification of taxable
> persons in Northern Ireland.
>
> This pull request 
> proposes updates to the EV Guidelines to allow those additional prefixes.
> It also fixes some formatting issues.
>
> The following motion has been proposed by Dimitris Zacharopoulos of HARICA
> and endorsed by Ben Wilson of Mozilla and Corey Bonnell of Digicert.
>
> MOTION BEGINS
>
> This ballot modifies the “Guidelines for the Issuance and Management of
> Extended Validation Certificates” (“EV Guidelines”), based on Version 1.8.0.
>
> MODIFY the EV Guidelines as specified in the following Redline:
>
>-
>
> https://github.com/cabforum/servercert/compare/da89d0e9700c6dd89a8263526addc39f472bf54c
>.
>
> MOTION ENDS
> The procedure for this ballot is as follows:
>
>
> *Start time (8:00 UTC)* *End time (8:00 UTC)*
> Discussion (at least 7 days) 2024-01-16 2024-01-23
> Expected Vote for approval (7 days) 2024-01-23
> 2024-01-30
> ___
> 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

Re: [Servercert-wg] Section 7.1.5 as required by RFC 3647 is no longer in the TLS BRs

[Ben Wilson via Servercert-wg]

I think this is listed as an issue in GitHub -
https://github.com/cabforum/servercert/issues/444.

On Thu, Jan 4, 2024 at 4:54 AM Dimitris Zacharopoulos (HARICA) via
Servercert-wg  wrote:

> Dear Members,
>
> While taking another pass at reviewing the new certificate profiles
> introduced in ballot SC62, I realized that there is some deviation from the
> RFC 3647 structure that the BRs should maintain to help alignment of CA
> CP/CPS documents.
>
> This is the structure defined by RFC 3647 for section 7:
>
>7.  CERTIFICATE, CRL, AND OCSP PROFILES
>7.1  Certificate profile
>7.1.1  Version number(s)
>7.1.2  Certificate extensions
>7.1.3  Algorithm object identifiers
>7.1.4  Name forms
>7.1.5  Name constraints
>7.1.6  Certificate policy object identifier
>7.1.7  Usage of Policy Constraints extension
>7.1.8  Policy qualifiers syntax and semantics
>7.1.9  Processing semantics for the critical Certificate Policies
>
>
> Section 7.1.5 does not exist anymore. The BRs have the name constraints
> information in 7.1.2.5.2, 7.1.2.10.8. I believe that, at a minimum, we
> should re-introduce 7.1.5 and point to other subsections of 7.1.2 for
> consistency with RFC 3647.
>
> Thoughts?
> Dimitris.
>
> ___
> 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

Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format pre-ballot

[Ben Wilson via Servercert-wg]

All,
See
https://github.com/BenWilson-Mozilla/pkipolicy/commit/1a94642cb95017cf382e4e93811db16a2342a806.
This proposed change was to clarify that the outline in section 6 of RFC
3647 is what is intended to be followed in CPs and CPSes, and not some
other outline found in RFC 3647.  Unfortunately, this change did not make
it into Mozilla Root Store Policy v. 2.9, but it is slated for inclusion in
version 3.0.
Thanks,
Ben

On Sat, Dec 2, 2023 at 3:26 AM Dimitris Zacharopoulos (HARICA) via
Servercert-wg  wrote:

> We still have a disagreement so please allow me one more attempt to
> clarify my position because it seems you didn't check the links included in
> my previous post. I will copy some of that text here for convenience.
>
> On 1/12/2023 11:31 μ.μ., Tim Hollebeek wrote:
>
> No.
>
>
>
> IETF has both Normative and Informative RFCs.  While it is true that
> compliance with a Normative RFC is voluntary, if you do choose to comply,
> the RFC has requirements stated in RFC 2119 standards language that make it
> clear what the compliance rules are.  Informative RFCs like 3647 do not
> have any normative requirements at all.  They merely contain information.
>
>
>
> “all sections of the RFC 3647 framework” is fine, this covers the sections
> enumerated in RFC 3647 section 4, which includes the TOP TWO levels of an
> outline in numbered form, e.g. the requirements for section 3.2 are
> described in RFC 3647 section 4.3.2.  There is no RFC 3647 section 4.3.2.1,
> which proves my point.  RFC 3647 only has a two level outline structure.
>
>
> I think I might have a hint on our disconnect. RFC 3647 has an indicative
> Table of Contents in Chapter 6 (
> https://datatracker.ietf.org/doc/html/rfc3647#section-6) outlining the
> proposed CP/CPS sections and subsections using 3 levels.
>
> Here is the text of the opening paragraph of that section (emphasis added):
>
>This section contains a recommended outline for a set of provisions,
>intended to serve as a checklist or (with some further development) a
>standard template for use by CP or CPS writers.  Such a common
>outline will facilitate:
>
>(a) Comparison of two certificate policies during cross-
>certification or other forms of interoperation (for the purpose
>of equivalency mapping).
>
>(b) Comparison of a CPS with a CP to ensure that the CPS faithfully
>implements the policy.
>
>(c) Comparison of two CPSs.
> *   In order to comply with the RFC, the drafters of a compliant CP or
>CPS are strongly advised to adhere to this outline.*  While use of an
>alternate outline is discouraged, it may be accepted if a proper
>justification is provided for the deviation and a mapping table is
>provided to readily discern where each of the items described in this
>outline is provided.
>
>
> The reason the CA/B Forum BRs were structured according to this outline
> was to assist with comparisons between CP/CPS documents of different CAs,
> making the review of these documents easier.
>
> That's why you see sections like 1.5.4 "CPS approval procedures" in the
> BRs as an empty section with "No Stipulation". There are many such sections
> in the BRs, all coming from section 6 of RFC 3647.
>
> I hope this is clearer now.
>
>
>
> BR Section 2.2 needs to be re-written, as there are no materials required
> by RFC 3647 (because RFC 3647 contains no requirements).  It needs to say
> something like “structured in accordance with RFC 3647 and MUST include all
> sections of the outline described in section 4” or something like that.
> What it says right now doesn’t capture the intent that you correctly
> summarized.
>
>
> During the last couple of years reviewing CP/CPS documents, I saw some
> uniformity at least in Publicly Trusted CAs, and they all seem to follow
> the BRs structure which comes from the outline of section 6 of RFC 3647.
> However, it's not a bad idea to further clarify BR section 2.2 to better
> meet the expectations.
>
>
>
> The MSRP language is better, I think I may have made all of these same
> points when it was being drafted, which is why it says “section and
> subsection” (two levels) and uses “structured according to” and not
> “complies with the requirements of”.
>
>
>
> But anyway, this is all background that supports what I’ve been saying all
> along: BR 3.2 is a RFC 3647 section.  BR 3.2.1 **is not** a RFC 3647
> required section, nor is it even a section that is even mentioned in RFC
> 3647.  If you don’t believe me, please go to RFC 3647, Section 4.3.2.1 and
> read what it says.  OH, WAIT, IT DOESN’T EXIST! 
>
>
> To my point, BR 3.2.1 IS an RFC 3647 required section as it is explicitly
> mentioned in the outline of section 6 of RFC 3647:
>
> 3.2.1  Method to prove possession of private key
>
>
> Details about the contents of that section can be found in the first
> bullet of section 4.3.2 of RFC 3647
> .
>
> Does that make 

Re: [Servercert-wg] Draft Ballot SC-067: Applicant, Subscriber and Subscriber Agreements - Feedback requested

[Ben Wilson via Servercert-wg]

Just inside lines 276-279, I suggest we replace "Applicant" with
"Applicant/Subscriber" so it would read:

**Applicant/Subscriber Representative**: A natural person or human sponsor
who is either the Applicant/Subscriber, employed by the
Applicant/Subscriber, or an authorized agent who has express authority to
represent the Applicant/Subscriber:

  i. who signs and submits, or approves a certificate request on behalf of
the Applicant/Subscriber, and/or

  ii. who accepts a Subscriber Agreement on behalf of the
Applicant/Subscriber.

Thanks,

Ben

On Wed, Oct 25, 2023 at 7:47 PM Dustin Hollenback via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> Hello all,
>
>
>
> This is a request for feedback for this draft ballot.
>
>
>
> Thank you,
>
>
>
>
>
> Dustin
>
>
>
>
>
>
> ---
>
>
>
> *Purpose of Ballot SC-067*
>
> 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". It also modifies
> details related to Subscriber, Applicant, and representatives for them.
>
>
>
> 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 “Applicant”, “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.
>
> •  This adds a new definition for “Applicant/Subscriber” to
> account for scenarios where a person or entity may be either. And renames
> “Applicant Representative” to “Applicant/Subscriber Representative” and
> updated definition to account for reseller scenarios.
>
> •  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.2).
>
> •  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.1.
>
>
>
> MODIFY the Baseline Requirements as specified in the following Redline:
>
>
>
> Here is a link to the GitHub redline:
>
>
> https://github.com/cabforum/servercert/compare/90a98dc7c1131eaab01af411968aa7330d315b9b...9eebd9949810f698edd5087235acaf16e04ead21
>
>
>
> *— Motion Ends —*
>
>
>
> This ballot proposes a Final Maintenance Guideline. The procedure for
> approval of this ballot is as follows:
>
>
>
> *Discussion (7+ days)*
>
> • Start time: -XX-XX 22:00:00 UTC
>
> • End time: -XX-XX 22: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

Re: [Servercert-wg] Draft Ballot SC-0XX: Subscriber Agreement and Terms of Use Consolidation

[Ben Wilson via Servercert-wg]

 All,

Dustin and I made the change suggested by Bruce -
https://github.com/BenWilson-Mozilla/servercert/commit/47423176206cca97eb8d4c3678f65f26f587c3c5

We modified item 4 in BR section 9.6.3, as discussed during the Validation
Subcommittee meeting a few weeks ago:
https://github.com/BenWilson-Mozilla/servercert/commit/87995c75537c5bfbc8694eab615a1ed807ec1415

Yesterday, I made additional edits to the draft ballot language.

Here they are:

In BR section 4.9.1.1, replaced Applicant with Subscriber

https://github.com/BenWilson-Mozilla/servercert/commit/b9e842395baf337b76cd55a3b5b3f89195838780

In BR section 9.6.3, replaced Applicant and Subscriber with
Applicant/Subscriber.

https://github.com/BenWilson-Mozilla/servercert/commit/da6cc2c6a7534f327be9ef03310ad270d375a961

Changed definition of Applicant and added definition of Applicant/Subscriber

https://github.com/BenWilson-Mozilla/servercert/commit/a017d5092583365e8b330e87f794639821aac056

Changed Applicant to Applicant/Subscriber in third paragraph of BR section 3.2.5

https://github.com/BenWilson-Mozilla/servercert/commit/105bba5145c9ad0b157b81f544a603206c02f31b

We are seeking one more endorser to work on this with us and to get a
ballot number assigned to this effort.

Also, we are preparing to review this ballot language during the Server
Certificate WG meeting at the F2F next Wednesday afternoon.

Thanks,

Ben


On Wed, Sep 6, 2023 at 12:05 PM Dustin Hollenback via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> Thanks for the suggestion, Bruce. We’ll incorporate the definition change
> into the next revision of the draft ballot.
>
> “**Subscriber Agreement**: A set of terms and conditions accepted by the
> Applicant/Subscriber that specifies the rights and responsibilities of the
> Applicant/Subscriber and the CA.”
>
>
>
>
>
> *From:* Bruce Morton 
> *Sent:* Tuesday, September 5, 2023 12:04 PM
> *To:* Dustin Hollenback ; CA/B Forum
> Server Certificate WG Public Discussion List 
> *Subject:* [EXTERNAL] RE: Draft Ballot SC-0XX: Subscriber Agreement and
> Terms of Use Consolidation
>
>
>
> You don't often get email from bruce.mor...@entrust.com. Learn why this
> is important 
>
> Hi Dustin,
>
>
>
> Thanks for the update. Would still like to know why the Subscriber
> Agreement definition is so narrow, “Provisions that the
> Applicant/Subscriber accepts regarding the safekeeping and acceptable uses
> of the Key Pair and Certificate issued in accordance with these
> Requirements”, but the TLS BRs items to be included which are greater than
> this scope?
>
>
>
> Entrust would prefer the definition to be, “A set of terms and conditions
> accepted by the Applicant/Subscriber that specifies the rights and
> responsibilities of the Applicant/Subscriber and the CA.” Would be great to
> get your feedback on this proposal.
>
>
>
>
>
> Thanks again, Bruce.
>
>
>
> *From:* Servercert-wg  *On Behalf Of 
> *Dustin
> Hollenback via Servercert-wg
> *Sent:* Friday, September 1, 2023 9:41 PM
> *To:* servercert-wg@cabforum.org
> *Subject:* [EXTERNAL] [Servercert-wg] Draft Ballot SC-0XX: Subscriber
> Agreement and Terms of Use Consolidation
>
>
>
> Hello all, We are looking for feedback on the following draft ballot as
> well as endorsers. Thank you, Dustin
> --
>
>
>
>
> Hello all,
>
>
>
> We are looking for feedback on the following draft ballot as well as
> endorsers.
>
> Thank you,
>
>
>
>
>
> Dustin
>
>
>
>
> --
>
>
>
> *Purpose of Ballot SC-0XX: Subscriber Agreement and Terms of Use
> Consolidation*
>
> 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.
>
> •  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.2).
>
>
>
>
>
> The following motion has been 

Re: [Servercert-wg] Proposed Revision of SCWG Charter

[Ben Wilson via Servercert-wg]

;>
>>> Hi all,
>>>
>>> I have a very different proposal for a Certificate Consumer membership
>>> criterion. I have no objection to any of the currently-proposed criteria;
>>> this could easily be in addition to them. What if we added:
>>>
>>> > (c) Applicants that qualify as Certificate Consumers must supply the
>>> following additional information:
>>> > - URL for its list of CA certificates that its membership-qualifying
>>> software product uses to validate the chain of trust from a TLS certificate
>>> to a CA certificate in such list; and
>>> > *- URL for the Certificate Transparency log which it operates within
>>>  and which accepts all submissions for TLS
>>> certificates which chain up to any CA certificate in the list above*;
>>> and
>>>
>>> Frankly, the Certificate Transparency ecosystem is in peril at the
>>> moment. With the recent shutdown of Sectigo's Mammoth
>>> <https://groups.google.com/a/chromium.org/g/ct-policy/c/Ebj2hhe5QYA/m/Cl7IW33UAgAJ>
>>> log and retirement of DigiCert's Yeti
>>> <https://groups.google.com/a/chromium.org/g/ct-policy/c/PVbs0ZMVeCI/m/Hf8kwuuAAQAJ>
>>> and Nessie
>>> <https://groups.google.com/a/chromium.org/g/ct-policy/c/MXLJFHdHdFo>
>>> logs, the already-tiny handful of organizations
>>> <https://googlechrome.github.io/CertificateTransparency/log_list.html> 
>>> operating
>>> usable CT logs is feeling even smaller. So what if Certificate Consumers --
>>> the organizations which benefit most from a diverse and robust ecosystem of
>>> CT logs -- were required to bring their own to the table? Running a CT log
>>> is clearly non-trivial, so such a requirement would effectively demonstrate
>>> that potential Certificate Consumer members are serious about operating for
>>> the good of the ecosystem in the long term.
>>>
>>> Thanks,
>>> Aaron
>>>
>>> On Fri, Sep 1, 2023 at 1:42 AM Martijn Katerbarg via Servercert-wg <
>>> servercert-wg@cabforum.org> wrote:
>>>
>>>> Ben,
>>>>
>>>>
>>>>
>>>> This seems like a good option. I’d say maybe we need to increase the 6
>>>> months period to 12, otherwise within a 6 months period there may only be 1
>>>> F2F. Requiring attendance (remote or in-person) if there’s only 1 F2F in
>>>> the time-span, could be hard if there’s a case of bad timing.
>>>>
>>>>
>>>>
>>>> Additionally, I’d like to request the addition of an additional
>>>> criteria (although it’s related to the “publish how it decides to add or
>>>> remove a CA certificate from its list.” item. I’d like to request we add a
>>>> requirement to:
>>>>
>>>>
>>>>
>>>>- Publish how a CA can apply for inclusion in its root store
>>>>
>>>>
>>>>
>>>> With this addition, I’d be happy to endorse
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Martijn
>>>>
>>>>
>>>>
>>>> *From:* Servercert-wg  *On Behalf
>>>> Of *Ben Wilson via Servercert-wg
>>>> *Sent:* Thursday, 31 August 2023 00:50
>>>> *To:* CA/B Forum Server Certificate WG Public Discussion List <
>>>> servercert-wg@cabforum.org>
>>>> *Subject:* [Servercert-wg] Proposed Revision of SCWG Charter
>>>>
>>>>
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>> All,
>>>>
>>>>
>>>>
>>>> Thanks for your suggestions and recommendations. I think we are much
>>>> closer to an acceptable revision of the Server Certificate Working Group
>>>> Charter. Here is the current draft:
>>>> https://github.com/cabforum/forum/blob/BenWilson-SCWG-charter-1.3/SCWG-charter.md
>>>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fforum%2Fblob%2FBenWilson-SCWG-charter-1.3%2FSCWG-charter.md=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C8b9a53bc77c6445114a808dba9ab7821%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638290326178847047%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%

Re: [Servercert-wg] Proposed Revision of SCWG Charter

[Ben Wilson via Servercert-wg]

Thanks, Martijn and Aaron,

Aaron, I don't think I can add a CT-support requirement for Certificate
Consumers at this time, although we can take the issue up for further
conversation.

Martijn, So that the duration of the probationary period is kept to six
months, it might be better to eliminate the F2F attendance requirement. If
we keep it, then a probationary member might have to wait until the next
F2F (but certainly not a year).  How do people feel about this?

Also, I have received feedback regarding whether a Certificate Consumer
should be required to "maintain" a full list of CAs. (I think I didn't have
the term "maintain" in the GitHub draft of the charter, so I'm thinking
that we might eliminate the term from the proposal.) Similarly, I'm
concerned that a requirement to publish "how a CA can apply for inclusion
in its root store" might make it less likely for a ballot to pass. So,
instead of "maintaining" a (full) list, what if we left it just, "(4) its
membership-qualifying software product uses a list of CA certificates to
validate the chain of trust from a TLS certificate to a CA certificate in
such list"?  What are everyone's thoughts on this?

Thanks,

Ben

On Thu, Sep 14, 2023 at 9:23 AM Aaron Gable  wrote:

> Hi all,
>
> I have a very different proposal for a Certificate Consumer membership
> criterion. I have no objection to any of the currently-proposed criteria;
> this could easily be in addition to them. What if we added:
>
> > (c) Applicants that qualify as Certificate Consumers must supply the
> following additional information:
> > - URL for its list of CA certificates that its membership-qualifying
> software product uses to validate the chain of trust from a TLS certificate
> to a CA certificate in such list; and
> > *- URL for the Certificate Transparency log which it operates within
>  and which accepts all submissions for TLS
> certificates which chain up to any CA certificate in the list above*; and
>
> Frankly, the Certificate Transparency ecosystem is in peril at the moment.
> With the recent shutdown of Sectigo's Mammoth
> <https://groups.google.com/a/chromium.org/g/ct-policy/c/Ebj2hhe5QYA/m/Cl7IW33UAgAJ>
> log and retirement of DigiCert's Yeti
> <https://groups.google.com/a/chromium.org/g/ct-policy/c/PVbs0ZMVeCI/m/Hf8kwuuAAQAJ>
> and Nessie
> <https://groups.google.com/a/chromium.org/g/ct-policy/c/MXLJFHdHdFo>
> logs, the already-tiny handful of organizations
> <https://googlechrome.github.io/CertificateTransparency/log_list.html> 
> operating
> usable CT logs is feeling even smaller. So what if Certificate Consumers --
> the organizations which benefit most from a diverse and robust ecosystem of
> CT logs -- were required to bring their own to the table? Running a CT log
> is clearly non-trivial, so such a requirement would effectively demonstrate
> that potential Certificate Consumer members are serious about operating for
> the good of the ecosystem in the long term.
>
> Thanks,
> Aaron
>
> On Fri, Sep 1, 2023 at 1:42 AM Martijn Katerbarg via Servercert-wg <
> servercert-wg@cabforum.org> wrote:
>
>> Ben,
>>
>>
>>
>> This seems like a good option. I’d say maybe we need to increase the 6
>> months period to 12, otherwise within a 6 months period there may only be 1
>> F2F. Requiring attendance (remote or in-person) if there’s only 1 F2F in
>> the time-span, could be hard if there’s a case of bad timing.
>>
>>
>>
>> Additionally, I’d like to request the addition of an additional criteria
>> (although it’s related to the “publish how it decides to add or remove a CA
>> certificate from its list.” item. I’d like to request we add a requirement
>> to:
>>
>>
>>
>>- Publish how a CA can apply for inclusion in its root store
>>
>>
>>
>> With this addition, I’d be happy to endorse
>>
>>
>>
>> Regards,
>>
>> Martijn
>>
>>
>>
>> *From:* Servercert-wg  *On Behalf Of
>> *Ben Wilson via Servercert-wg
>> *Sent:* Thursday, 31 August 2023 00:50
>> *To:* CA/B Forum Server Certificate WG Public Discussion List <
>> servercert-wg@cabforum.org>
>> *Subject:* [Servercert-wg] Proposed Revision of SCWG Charter
>>
>>
>>
>> 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.
>>
>>
>>
>> All,
>>
>>
>>
>> Thanks for your suggestions and recommendations. I think we are much
>> closer to an acceptable revision of the Server Certificate Working Grou

[Servercert-wg] Proposed Revision of SCWG Charter

[Ben Wilson via Servercert-wg]

All,

Thanks for your suggestions and recommendations. I think we are much closer
to an acceptable revision of the Server Certificate Working Group Charter.
Here is the current draft:
https://github.com/cabforum/forum/blob/BenWilson-SCWG-charter-1.3/SCWG-charter.md

We have decided that a participation/attendance requirement for ongoing
membership is currently too complicated to manage, but we believe it is
important that there be a probationary period of six months during which
all new CABF-voting applicants must attend at least 30% of the
teleconferences and at least the SCWG portion of one F2F (virtually or
in-person). See section 4(d) in the draft cited above. We believe that with
this limited scope, we can and should measure attendance to ensure that
prospective members are serious about participating in the Forum.

We no longer seek to require that a Certificate Consumer have any
particular size or user base (or that they meet other criteria that were
floated in recent emails).  Those criteria were also currently too
complicated. However, in addition to those Certificate Consumer
requirements that are in the existing charter, we want a Certificate
Consumer to:

   - have public documentation stating that it requires Certificate Issuers
   to comply with the TLS Baseline Requirements;
   - maintain a list of CA certificates used to validate the chain of trust
   from a TLS certificate to a CA certificate in such list; and
   - publish how it decides to add or remove a CA certificate from its list.

I am looking for two endorsers of a FORUM ballot, so if the
above-referenced draft is generally acceptable, please contact me, and we
can work out any remaining details.

Thanks,

Ben


On Tue, Jul 25, 2023 at 11:07 PM Roman Fischer via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> Dear Ben,
>
>
>
> I like your two new suggestions as they offer more lightweight mechanisms.
>
>
>
> One other idea (completely ad hoc and not really thought through) would be
> to change the charter to allow suspension of members from the SCWG by
> ballot. That way a ballot could be proposed, discussed, endorsed and voted
> on. And since the state of “suspended membership” is well defined
> (including the way back to full membership), this might offer the “accused”
> member enough possibility to counter the “allegations” made in the ballot.
> It would also make transparent who wants to suspend whom for what reasons…
>
>
>
> Kind regards
> Roman
>
>
>
> *From:* Ben Wilson 
> *Sent:* Dienstag, 25. Juli 2023 17:40
> *To:* Roman Fischer 
> *Cc:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg@cabforum.org>
> *Subject:* Re: [Servercert-wg] Participation Proposal for Revised SCWG
> Charter
>
>
>
> Thanks for your insights, Roman.
>
>
>
> I'm not yet convinced that the attendance approach would not be effective.
> Nevertheless, here are some other potential alternatives to discuss:
>
>
>
> 1 - require that a Certificate Consumer have a certain size userbase, or
> alternatively, that they be a Root Store member of the Common CA Database
> <https://www.ccadb.org/rootstores/how>, or
>
> 2 - require that a Certificate Consumer pay a membership fee to the
> CA/Browser Forum.
>
>
>
> Does anyone have any other ideas, proposals, or suggestions that we can
> discuss?
>
>
>
> The approaches listed above would be in addition to the following other
> requirements already proposed:
>
>
>
> The Certificate Consumer has public documentation stating that it requires
> Certification Authorities to comply with the CA/Browser Forum’s Baseline
> Requirements for the issuance and maintenance of TLS server
> certificates; its membership-qualifying software product uses a list of CA
> certificates to validate the chain of trust from a TLS certificate to a CA
> certificate in such list; and it publishes how it decides to add or remove
> a CA certificate from the root store used in its membership-qualifying
> software product.
>
>
>
> Thanks,
>
>
>
> Ben
>
>
>
> On Mon, Jul 24, 2023 at 10:48 PM Roman Fischer <
> roman.fisc...@swisssign.com> wrote:
>
> Dear Ben,
>
>
>
> As stated before, I’m against minimal attendance (or even participation –
> however you would measure that, numbers of words spoken or written?)
> requirements. I’ve seen in university, in private associations, policitcs…
> that this simply doesn’t solve the problem. I totally agree with Tim: It
> will create administrative overhead and not solve the problem.
>
>
>
> IMHO non-particpants taking part in the democratic process (i.e. voting)
> is just something we have to accept and factor in. It’s one end of the
> extreme spectrum. There might be 

Re: [Servercert-wg] SC-XXX: Modify Subscriber Agreement and Terms of Use

[Ben Wilson via Servercert-wg]

Hi Clint,

Basically, that's about it, except by removing the separate "Terms of Use"
and collapsing that concept into "Subscriber Agreement" there are places
where "agreeing" and "legally binding" may get watered down. "Agree" is
replaced with "accept" in some places, and in two places "legally binding"
is preserved for unaffiliated parties but not between affiliates (line 3364
and line 3380), but I don't think that make the proposed language less
protective than it is with the current "Terms of Use" language.

That being said, we could expand the scope of the ballot to address other
"Subscriber Agreement" issues, if anyone can articulate them and present
acceptable language that would address them.

Dustin Hollenback is the proposer of this ballot, so he may have additional
points he'd like to make or clarify.

Thanks,
Ben

On Wed, Aug 16, 2023 at 12:29 PM Clint Wilson  wrote:

> Hi Ben,
>
> As I understand it the goal of these changes is just to simplify the terms
> used in the BRs — and, as has been brought up separately, potentially other
> CA/BF Final Guidelines — in order to enable collapsing their use of “Terms
> of Use” into the concept of the “Subscriber Agreement”. Is that an accurate
> description of the intent of this draft? Are there any other goals or
> outcomes being aimed at with these changes?
>
> Thanks!
> -Clint
>
> On Aug 14, 2023, at 12:40 PM, Ben Wilson via Servercert-wg <
> servercert-wg@cabforum.org> wrote:
>
> Hi,
> Dustin Hollenback and I are looking for another endorser for a proposed
> ballot - see
> https://github.com/cabforum/servercert/compare/a0360b61e73476959220dc328e3b68d0224fa0b3..663695b8319c0cd32e0060bb9304ecd32e3737a1
> It would remove the concept of a separate "Terms of Use" and replace it
> with "Subscriber Agreement" and make several other changes with respect to
> "Subscriber Agreements".
> Is anyone interested in endorsing?
> Thanks,
> Ben
> ___
> 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] SC-XXX: Modify Subscriber Agreement and Terms of Use

[Ben Wilson via Servercert-wg]

Hi,
Dustin Hollenback and I are looking for another endorser for a proposed
ballot - see
https://github.com/cabforum/servercert/compare/a0360b61e73476959220dc328e3b68d0224fa0b3..663695b8319c0cd32e0060bb9304ecd32e3737a1
It would remove the concept of a separate "Terms of Use" and replace it
with "Subscriber Agreement" and make several other changes with respect to
"Subscriber Agreements".
Is anyone interested in endorsing?
Thanks,
Ben
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] Participation Proposal for Revised SCWG Charter

[Ben Wilson via Servercert-wg]

Thanks for your insights, Roman.

I'm not yet convinced that the attendance approach would not be effective.
Nevertheless, here are some other potential alternatives to discuss:

1 - require that a Certificate Consumer have a certain size userbase, or
alternatively, that they be a Root Store member of the Common CA Database
<https://www.ccadb.org/rootstores/how>, or
2 - require that a Certificate Consumer pay a membership fee to the
CA/Browser Forum.

Does anyone have any other ideas, proposals, or suggestions that we can
discuss?

The approaches listed above would be in addition to the following other
requirements already proposed:

The Certificate Consumer has public documentation stating that it requires
Certification Authorities to comply with the CA/Browser Forum’s Baseline
Requirements for the issuance and maintenance of TLS server certificates; its
membership-qualifying software product uses a list of CA certificates to
validate the chain of trust from a TLS certificate to a CA certificate in
such list; and it publishes how it decides to add or remove a CA
certificate from the root store used in its membership-qualifying software
product.

Thanks,

Ben

On Mon, Jul 24, 2023 at 10:48 PM Roman Fischer 
wrote:

> Dear Ben,
>
>
>
> As stated before, I’m against minimal attendance (or even participation –
> however you would measure that, numbers of words spoken or written?)
> requirements. I’ve seen in university, in private associations, policitcs…
> that this simply doesn’t solve the problem. I totally agree with Tim: It
> will create administrative overhead and not solve the problem.
>
>
>
> IMHO non-particpants taking part in the democratic process (i.e. voting)
> is just something we have to accept and factor in. It’s one end of the
> extreme spectrum. There might be over-active participants that overwhelm
> the group by pushing their own agenda… If we have minimum participation
> requirements, then we maybe should also have maximum participation rules?
> 
>
>
>
> Rgds
> Roman
>
>
>
> *From:* Servercert-wg  *On Behalf Of *Ben
> Wilson via Servercert-wg
> *Sent:* Montag, 24. Juli 2023 21:40
> *To:* Tim Hollebeek ; CA/B Forum Server
> Certificate WG Public Discussion List 
> *Subject:* Re: [Servercert-wg] Participation Proposal for Revised SCWG
> Charter
>
>
>
> Tim,
>
> One problem we're trying to address is the potential for a great number of
> “submarine voters”.  Such members may remain inactive for extended periods
> of time and then surface only to vote for or against something they
> suddenly are urged to support or oppose, without being aware of the
> issues.  This will skew and damage the decision-making process.
>
> Another problem, that I don't think has been mentioned before, is the
> reliability of the CA/Browser Forum to adopt well-informed standards going
> forward.  In other words, if something like I suggest happens, then I can
> see Certificate Consumers leaving the Forum and unilaterally setting very
> separate and distinct rules. This will result in fragmentation,
> inconsistency, and much more management overhead for CAs than the effort
> needed to keep track of attendance, which is already being done by the
> Forum.  (If you'd like, I can share with everyone the list of members who
> have not voted or attended meetings in over two years.)
>
> Ben
>
>
>
> On Mon, Jul 24, 2023 at 11:41 AM Tim Hollebeek 
> wrote:
>
> What is your argument in response to the point that any potential bad
> actors will be trivially able to satisfy the participation metrics?
>
>
>
> I’m very worried we’ll end up doing a lot of management and tracking work,
> without actually solving the problem.
>
>
>
> -Tim
>
>
>
> *From:* Ben Wilson 
> *Sent:* Monday, July 24, 2023 10:21 AM
> *To:* Ben Wilson ; CA/B Forum Server Certificate WG
> Public Discussion List 
> *Cc:* Tim Hollebeek 
> *Subject:* Re: [Servercert-wg] Participation Proposal for Revised SCWG
> Charter
>
>
>
> All,
>
> I have thought a lot about this, including various other formulas (e.g.
> market share) to come up with something reasonable, but I've come back to
> attendance as the key metric that we need to focus on. I just think that an
> attendance metric provides the only workable, measurable, and sound
> solution for determining the right to vote as a Certificate Consumer
> because it offers the following three elements:
>
>- Informed Decision-Making: Voting requires a comprehensive
>understanding of ongoing discussions and developments. Regular attendance
>provides members with the necessary context and knowledge to make
>well-informed decisions.
>- Commitment: Attendance is a tangible and measurable representation

Re: [Servercert-wg] Participation Proposal for Revised SCWG Charter

[Ben Wilson via Servercert-wg]

Tim,

One problem we're trying to address is the potential for a great number of
“submarine voters”.  Such members may remain inactive for extended periods
of time and then surface only to vote for or against something they
suddenly are urged to support or oppose, without being aware of the issues.
This will skew and damage the decision-making process.

Another problem, that I don't think has been mentioned before, is the
reliability of the CA/Browser Forum to adopt well-informed standards going
forward.  In other words, if something like I suggest happens, then I can
see Certificate Consumers leaving the Forum and unilaterally setting very
separate and distinct rules. This will result in fragmentation,
inconsistency, and much more management overhead for CAs than the effort
needed to keep track of attendance, which is already being done by the
Forum.  (If you'd like, I can share with everyone the list of members who
have not voted or attended meetings in over two years.)

Ben

On Mon, Jul 24, 2023 at 11:41 AM Tim Hollebeek 
wrote:

> What is your argument in response to the point that any potential bad
> actors will be trivially able to satisfy the participation metrics?
>
>
>
> I’m very worried we’ll end up doing a lot of management and tracking work,
> without actually solving the problem.
>
>
>
> -Tim
>
>
>
> *From:* Ben Wilson 
> *Sent:* Monday, July 24, 2023 10:21 AM
> *To:* Ben Wilson ; CA/B Forum Server Certificate WG
> Public Discussion List 
> *Cc:* Tim Hollebeek 
> *Subject:* Re: [Servercert-wg] Participation Proposal for Revised SCWG
> Charter
>
>
>
> All,
>
> I have thought a lot about this, including various other formulas (e.g.
> market share) to come up with something reasonable, but I've come back to
> attendance as the key metric that we need to focus on. I just think that an
> attendance metric provides the only workable, measurable, and sound
> solution for determining the right to vote as a Certificate Consumer
> because it offers the following three elements:
>
>- Informed Decision-Making: Voting requires a comprehensive
>understanding of ongoing discussions and developments. Regular attendance
>provides members with the necessary context and knowledge to make
>well-informed decisions.
>- Commitment: Attendance is a tangible and measurable representation
>of a member's commitment to the Server Certificate WG and its objectives.
>It demonstrates a genuine interest in contributing to the development and
>improvement of the requirements.
>- Active Involvement: By prioritizing attendance, we encourage active
>involvement and discourage passive membership. Voting rights should be
>earned through consistent engagement, as this ensures that decisions are
>made by those who are genuinely invested in the outcomes.
>
> At this point, I'm going to re-draft a proposal for a revision to the
> Server Certificate WG Charter and present it on the public list (because an
> eventual revision of the Charter will have to take place at the Forum
> level).
>
> Thanks,
>
> Ben
>
>
>
> On Thu, Jul 13, 2023 at 9:45 AM Ben Wilson via Servercert-wg <
> servercert-wg@cabforum.org> wrote:
>
> Thanks, Tim.
>
>
>
> All,
>
>
>
> I will look closer at the distribution and use of software for browsing
> the internet securely, instead of participation metrics. There is at least
> one source, StatCounter (https://gs.statcounter.com/browser-market-share),
> that purports to measure use of browsing software, both globally and
> regionally. Would it be worthwhile to explore distribution by region and
> come up with a reasonable threshold?  Can we rely on StatCounter, or should
> we look elsewhere?
>
>
>
> Thanks,
>
>
>
> Ben
>
>
>
> On Wed, Jul 12, 2023 at 9:30 AM Tim Hollebeek via Servercert-wg <
> servercert-wg@cabforum.org> wrote:
>
> I have a meaningful comment.
>
>
>
> I don’t want to ever have to discuss or judge whether someone’s comment is
> “meaningful” or not, and I don’t think incentivizing people to post more
> comments than they otherwise would is helpful.
>
>
>
> I also think getting the chairs involved in any way in discussing whether
> a member representative did or did not have a medical condition during a
> particular time period is an extremely bad idea.
>
>
>
> Given that the original issue was trying to determine whether a
> certificate consumer is in fact a legitimate player in the ecosystem or
> not, I would suggest that exploring metrics like market share might be far
> more useful.  Metrics like participation are rather intrusive and onerous,
> except to those who are trying to game them, and those trying t

Re: [Servercert-wg] Participation Proposal for Revised SCWG Charter

[Ben Wilson via Servercert-wg]

All,

I have thought a lot about this, including various other formulas (e.g.
market share) to come up with something reasonable, but I've come back to
attendance as the key metric that we need to focus on. I just think that an
attendance metric provides the only workable, measurable, and sound
solution for determining the right to vote as a Certificate Consumer
because it offers the following three elements:

   - Informed Decision-Making: Voting requires a comprehensive
   understanding of ongoing discussions and developments. Regular attendance
   provides members with the necessary context and knowledge to make
   well-informed decisions.
   - Commitment: Attendance is a tangible and measurable representation of
   a member's commitment to the Server Certificate WG and its objectives. It
   demonstrates a genuine interest in contributing to the development and
   improvement of the requirements.
   - Active Involvement: By prioritizing attendance, we encourage active
   involvement and discourage passive membership. Voting rights should be
   earned through consistent engagement, as this ensures that decisions are
   made by those who are genuinely invested in the outcomes.

At this point, I'm going to re-draft a proposal for a revision to the
Server Certificate WG Charter and present it on the public list (because an
eventual revision of the Charter will have to take place at the Forum
level).

Thanks,

Ben


On Thu, Jul 13, 2023 at 9:45 AM Ben Wilson via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> Thanks, Tim.
>
> All,
>
> I will look closer at the distribution and use of software for browsing
> the internet securely, instead of participation metrics. There is at least
> one source, StatCounter (https://gs.statcounter.com/browser-market-share),
> that purports to measure use of browsing software, both globally and
> regionally. Would it be worthwhile to explore distribution by region and
> come up with a reasonable threshold?  Can we rely on StatCounter, or should
> we look elsewhere?
>
> Thanks,
>
> Ben
>
> On Wed, Jul 12, 2023 at 9:30 AM Tim Hollebeek via Servercert-wg <
> servercert-wg@cabforum.org> wrote:
>
>> I have a meaningful comment.
>>
>>
>>
>> I don’t want to ever have to discuss or judge whether someone’s comment
>> is “meaningful” or not, and I don’t think incentivizing people to post more
>> comments than they otherwise would is helpful.
>>
>>
>>
>> I also think getting the chairs involved in any way in discussing whether
>> a member representative did or did not have a medical condition during a
>> particular time period is an extremely bad idea.
>>
>>
>>
>> Given that the original issue was trying to determine whether a
>> certificate consumer is in fact a legitimate player in the ecosystem or
>> not, I would suggest that exploring metrics like market share might be far
>> more useful.  Metrics like participation are rather intrusive and onerous,
>> except to those who are trying to game them, and those trying to game such
>> metrics will succeed with little or no effort.
>>
>>
>>
>> -Tim
>>
>>
>>
>> *From:* Servercert-wg  *On Behalf Of
>> *Roman Fischer via Servercert-wg
>> *Sent:* Wednesday, July 12, 2023 7:23 AM
>> *To:* CA/B Forum Server Certificate WG Public Discussion List <
>> servercert-wg@cabforum.org>
>> *Subject:* Re: [Servercert-wg] Participation Proposal for Revised SCWG
>> Charter
>>
>>
>>
>> Dear Ben,
>>
>>
>>
>> Mandatory participation has in my experience never resulted in more or
>> better discussions. People will dial into the telco and let it run in the
>> background to “earn the credits”.
>>
>>
>>
>> Also, what would happen after the 90 day suspension? Would the
>> organization be removed as a CA/B member?
>>
>>
>>
>> Rgds
>> Roman
>>
>>
>>
>> *From:* Servercert-wg  *On Behalf Of
>> *Ben Wilson via Servercert-wg
>> *Sent:* Freitag, 7. Juli 2023 21:59
>> *To:* CA/B Forum Server Certificate WG Public Discussion List <
>> servercert-wg@cabforum.org>
>> *Subject:* [Servercert-wg] Participation Proposal for Revised SCWG
>> Charter
>>
>>
>>
>> All,
>>
>>
>>
>> Here is a draft participation proposal for the SCWG to consider and
>> discuss for inclusion in a revised SCWG Charter.
>>
>>
>>
>> #.  Participation Requirements to Maintain Voting Privileges
>>
>>
>>
>> (a) Attendance.  The privilege to vote “Yes” or “No” on ballots is
>> suspended for 90 days if a Voting Member fails to mee

Re: [Servercert-wg] Participation Proposal for Revised SCWG Charter

[Ben Wilson via Servercert-wg]

Thanks, Tim.

All,

I will look closer at the distribution and use of software for browsing the
internet securely, instead of participation metrics. There is at least one
source, StatCounter (https://gs.statcounter.com/browser-market-share), that
purports to measure use of browsing software, both globally and regionally.
Would it be worthwhile to explore distribution by region and come up with a
reasonable threshold?  Can we rely on StatCounter, or should we look
elsewhere?

Thanks,

Ben

On Wed, Jul 12, 2023 at 9:30 AM Tim Hollebeek via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> I have a meaningful comment.
>
>
>
> I don’t want to ever have to discuss or judge whether someone’s comment is
> “meaningful” or not, and I don’t think incentivizing people to post more
> comments than they otherwise would is helpful.
>
>
>
> I also think getting the chairs involved in any way in discussing whether
> a member representative did or did not have a medical condition during a
> particular time period is an extremely bad idea.
>
>
>
> Given that the original issue was trying to determine whether a
> certificate consumer is in fact a legitimate player in the ecosystem or
> not, I would suggest that exploring metrics like market share might be far
> more useful.  Metrics like participation are rather intrusive and onerous,
> except to those who are trying to game them, and those trying to game such
> metrics will succeed with little or no effort.
>
>
>
> -Tim
>
>
>
> *From:* Servercert-wg  *On Behalf Of 
> *Roman
> Fischer via Servercert-wg
> *Sent:* Wednesday, July 12, 2023 7:23 AM
> *To:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg@cabforum.org>
> *Subject:* Re: [Servercert-wg] Participation Proposal for Revised SCWG
> Charter
>
>
>
> Dear Ben,
>
>
>
> Mandatory participation has in my experience never resulted in more or
> better discussions. People will dial into the telco and let it run in the
> background to “earn the credits”.
>
>
>
> Also, what would happen after the 90 day suspension? Would the
> organization be removed as a CA/B member?
>
>
>
> Rgds
> Roman
>
>
>
> *From:* Servercert-wg  *On Behalf Of *Ben
> Wilson via Servercert-wg
> *Sent:* Freitag, 7. Juli 2023 21:59
> *To:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg@cabforum.org>
> *Subject:* [Servercert-wg] Participation Proposal for Revised SCWG Charter
>
>
>
> All,
>
>
>
> Here is a draft participation proposal for the SCWG to consider and
> discuss for inclusion in a revised SCWG Charter.
>
>
>
> #.  Participation Requirements to Maintain Voting Privileges
>
>
>
> (a) Attendance.  The privilege to vote “Yes” or “No” on ballots is
> suspended for 90 days if a Voting Member fails to meet the following
> attendance requirement over any 365-day period:
>
>- 10% of SCWG meetings for Voting Members located in time zones offset
>by UTC +5 through UTC +12
>- 30% of SCWG meetings for Voting Members located in all other time
>zones
>
> (b) Meaningful Comments.  Posting a Meaningful Comment is an alternative
> means of meeting the attendance requirement in subsection (a). A Voting
> Member can earn an attendance credit to make up for each missed meeting by
> posting a Meaningful Comment to the SCWG Public Mail List. Each Meaningful
> Comment is equal to attending one (1) meeting.
>
>
>
> A Meaningful Comment is one that follows the Code of Conduct and provides
> relevant information to the SCWG, such as new information, an insight,
> suggestion, or perspective related to the Scope of the SCWG, or that
> proposes an improvement to the TLS Baseline Requirements or EV Guidelines.
> It can also be something that responds to or builds on the comments of
> others in a meaningful way, or that offers feedback, suggestions, or
> solutions to the issues or challenges raised by the topic of discussion.
>
>
>
> A Meaningful Comment should be both relevant (within the Scope of the
> SCWG or related to the discussion that is taking place on the mailing
> list) and well-supported (clear reasons why the Voting Representative
> believes what they believe and supported by facts, data, or other
> information.)
>
>
>
> (c) A Voting Member that has failed to meet the attendance requirement in
> subsection (a) above is considered an "Inactive Member".  Any Member who
> believes that any other Member is an Inactive Member may report that Member
> on the Forum's Management List by providing specific information about that
> Member's non-participation, and the SCWG Chair shall send written notice
> to the Inact