Re: [Servercert-wg] Voting Period Begins: Ballot SC-078 - Subject organizationName alignment for DBA / Assumed Name

[Bruce Morton via Servercert-wg]

Entrust votes Yes to ballot SC-078.


Bruce.

From: Servercert-wg  On Behalf Of Martijn 
Katerbarg via Servercert-wg
Sent: Tuesday, September 17, 2024 9:20 AM
To: CA/B Forum Server Certificate WG Public Discussion List 

Subject: [EXTERNAL] [Servercert-wg] Voting Period Begins: Ballot SC-078 - 
Subject organizationName alignment for DBA / Assumed Name

Summary
The TLS Baseline Requirements currently state an OV certificate may contain 
either a DBA / Assumed Name or Legal Name. The EVGs and SBRs allow for the 
common format of "DBA (Legal Name)". This ballot aims to align the practices 
for OV certificates with this.

While still allowing the inclusion of the sole DBA / Assumed Name, it will also 
allow for the "DBA (Legal Name)" format to be used, allowing CAs to align 
practices with the EVG and SBRs.

The following motion has been proposed by Martijn Katerbarg (Sectigo) and 
endorsed by Clint Wilson (Apple) and Enrico Entschew (D-Trust).

Motion Begins
MODIFY the "Baseline Requirements for the Issuance and Management of 
Publicly-Trusted Certificates" ("Baseline Requirements") based on Version 2.0.7 
as specified in the following redline:

https://github.com/cabforum/servercert/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5...d69373c35ff72121a912b69b060ff89f32d41383

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-09-10 13:00 UTC
  *   End time: 2024-09-17 13:20 UTC

Vote for approval (7 days)

  *   Start time: 2024-09-17 13:20 UTC
  *   End time: 2024-09-24 13:20 UTC


Any email and files/attachments transmitted with it are intended solely for the 
use of the individual or entity to whom they are addressed. If this message has 
been sent to you in error, you must not copy, distribute or disclose of the 
information it contains. Please notify Entrust immediately and delete the 
message from your system.
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] [EXTERNAL] VOTING Period Begins - Ballot SC-077: Update WebTrust Audit name in Section 8.4 and References

[Bruce Morton via Servercert-wg]

Entrust votes Yes to ballot SC-077.


Bruce.

From: Servercert-wg  On Behalf Of Bruce 
Morton via Servercert-wg
Sent: Tuesday, August 13, 2024 2:34 PM
To: Clint Wilson ; CA/B Forum Server Certificate WG Public 
Discussion List 
Subject: Re: [Servercert-wg] [EXTERNAL] VOTING Period Begins - Ballot SC-077: 
Update WebTrust Audit name in Section 8.4 and References

Entrust votes Yes to ballot SC-007. Bruce. From: Servercert-wg 
 On Behalf Of Clint Wilson via 
Servercert-wg Sent: Tuesday, August 13, 2024 1: 05 PM To: ServerCert CA/BF 


Entrust votes Yes to ballot SC-007.


Bruce.

From: Servercert-wg 
mailto:servercert-wg-boun...@cabforum.org>> 
On Behalf Of Clint Wilson via Servercert-wg
Sent: Tuesday, August 13, 2024 1:05 PM
To: ServerCert CA/BF 
mailto:servercert-wg@cabforum.org>>
Subject: [EXTERNAL] [Servercert-wg] VOTING Period Begins - Ballot SC-077: 
Update WebTrust Audit name in Section 8.4 and References

Purpose of Ballot

CPA Canada has separated the audit criteria which map to the Network and 
Certificate System Security Requirements (NCSSRs) from the audit criteria which 
map to the TLS Baseline Requirements (TBRs). As a result, the requirements in 
Section 8.4 are out of date for audits which use the updated/separated audit 
criteria. However, we also need to ensure the combined audit criteria are able 
to be used until fully deprecated by CPA Canada and/or Root Programs stop 
accepting them.

This ballot modifies Section 8.4 to allow for a CA to be audited against either:

  *   WebTrust Principles and Criteria for Certification Authorities – SSL 
Baseline with Network Security; or
  *   WebTrust Principles and Criteria for Certification Authorities – SSL 
Baseline AND WebTrust Principles and Criteria for Certification Authorities – 
Network Security

Motion

The following motion has been proposed by Clint Wilson (Apple) and endorsed by 
Dimitris Zacharopoulos (HARICA) and Trevoli Ponds-White (Amazon)

You can view and comment on the Github pull request representing this ballot 
here<https://urldefense.com/v3/__https:/github.com/cabforum/servercert/pull/514/files__;!!FJ-Y8qCqXTj2!bzoJTDo1gSGYPLMzsie3divH8jpW88qahujxgnfDCdpbEsqEcFm5VqY5KnUwzO41Y3NMpo1ZBDDH3UdC7393exObqVEtfQ$>.

Motion Begins

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

  *   
https://github.com/cabforum/servercert/compare/20af1b271f2b689344ae353d3e78dc6b772199db...a9d3e3b6e514cf8b4d44ace625a447108c04a91c<https://urldefense.com/v3/__https:/github.com/cabforum/servercert/compare/20af1b271f2b689344ae353d3e78dc6b772199db...a9d3e3b6e514cf8b4d44ace625a447108c04a91c__;!!FJ-Y8qCqXTj2!bzoJTDo1gSGYPLMzsie3divH8jpW88qahujxgnfDCdpbEsqEcFm5VqY5KnUwzO41Y3NMpo1ZBDDH3UdC7393exOOqG-egg$>

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: August 6, 2024 17:00 UTC
  *   End time: on or after August 13, 2024 17:00 UTC

Vote for approval (7 days)

  *   Start time: August 13, 2024 17:00 UTC
  *   End time: August 20, 2024 17:00 UTC
Any email and files/attachments transmitted with it are intended solely for the 
use of the individual or entity to whom they are addressed. If this message has 
been sent to you in error, you must not copy, distribute or disclose of the 
information it contains. Please notify Entrust immediately and delete the 
message from your system.
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] [EXTERNAL] VOTING Period Begins - Ballot SC-077: Update WebTrust Audit name in Section 8.4 and References

[Bruce Morton via Servercert-wg]

Entrust votes Yes to ballot SC-007.


Bruce.

From: Servercert-wg  On Behalf Of Clint 
Wilson via Servercert-wg
Sent: Tuesday, August 13, 2024 1:05 PM
To: ServerCert CA/BF 
Subject: [EXTERNAL] [Servercert-wg] VOTING Period Begins - Ballot SC-077: 
Update WebTrust Audit name in Section 8.4 and References

Purpose of Ballot

CPA Canada has separated the audit criteria which map to the Network and 
Certificate System Security Requirements (NCSSRs) from the audit criteria which 
map to the TLS Baseline Requirements (TBRs). As a result, the requirements in 
Section 8.4 are out of date for audits which use the updated/separated audit 
criteria. However, we also need to ensure the combined audit criteria are able 
to be used until fully deprecated by CPA Canada and/or Root Programs stop 
accepting them.

This ballot modifies Section 8.4 to allow for a CA to be audited against either:

  *   WebTrust Principles and Criteria for Certification Authorities – SSL 
Baseline with Network Security; or
  *   WebTrust Principles and Criteria for Certification Authorities – SSL 
Baseline AND WebTrust Principles and Criteria for Certification Authorities – 
Network Security

Motion

The following motion has been proposed by Clint Wilson (Apple) and endorsed by 
Dimitris Zacharopoulos (HARICA) and Trevoli Ponds-White (Amazon)

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

Motion Begins

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

  *   
https://github.com/cabforum/servercert/compare/20af1b271f2b689344ae353d3e78dc6b772199db...a9d3e3b6e514cf8b4d44ace625a447108c04a91c

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: August 6, 2024 17:00 UTC
  *   End time: on or after August 13, 2024 17:00 UTC

Vote for approval (7 days)

  *   Start time: August 13, 2024 17:00 UTC
  *   End time: August 20, 2024 17:00 UTC

Any email and files/attachments transmitted with it are intended solely for the 
use of the individual or entity to whom they are addressed. If this message has 
been sent to you in error, you must not copy, distribute or disclose of the 
information it contains. Please notify Entrust immediately and delete the 
message from your system.
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] [EXTERNAL] Seeking endorsers for Ballot SC-076 "Clarify and improve OCSP requirements"

[Bruce Morton via Servercert-wg]

Hi Aaron,

Thanks for the ballot proposal.

I have feedback from our team is it would be great to have 3 months or so to 
make sure that this requirement as addressed properly - “Authoritative OCSP 
responses MUST be available (i.e. the responder MUST NOT respond with the 
"unknown" status) starting no more than 15 minutes after the certificate 
signing operation occurs.”

Could we add in an effective date for this requirement?


Thanks, Bruce.

From: Servercert-wg  On Behalf Of Aaron 
Gable via Servercert-wg
Sent: Friday, August 9, 2024 2:54 PM
To: CA/B Forum Server Certificate WG Public Discussion List 

Subject: [EXTERNAL] [Servercert-wg] Seeking endorsers for Ballot SC-076 
"Clarify and improve OCSP requirements"

This ballot has grown out of discussions around whether OCSP responses must be 
made available for Precertificates, and how quickly they must be made available 
after initial issuance. Much of that conversation is captured in this bugzilla 
incident and

This ballot has grown out of discussions around whether OCSP responses must be 
made available for Precertificates, and how quickly they must be made available 
after initial issuance. Much of that conversation is captured in this bugzilla 
incident
 and this Mozilla 
issue.

In addition, I've often felt like Sections 4.9.9 and 4.9.10 are poorly laid 
out, with little rhyme or reason as to why any particular requirement lives in 
one section or the other. RFC 3647 says that Section 4.9.10 is meant to place 
requirements on relying parties, not on CAs, which explains much of the 
confusion.

The result is a total rearrangement of Sections 4.9.9 and 4.9.10. This ballot 
empties 4.9.10, moves all of its requirements into 4.9.9, and arranges them 
into three sections:
- A few definitions (which apply only in this section);
- Requirements which apply to OCSP Responders whose URLs are found in the AIA 
OCSP field of certificates; and
- Requirements which apply to all OCSP Responses, regardless of how it was 
queried.

The PR representing this ballot is here: 
https://github.com/cabforum/servercert/pull/535

Please let me know if you have any comments or suggested changes on the GitHub 
PR, and please let me know if you'd be willing to endorse.

Thank you,
Aaron
Any email and files/attachments transmitted with it are intended solely for the 
use of the individual or entity to whom they are addressed. If this message has 
been sent to you in error, you must not copy, distribute or disclose of the 
information it contains. Please notify Entrust immediately and delete the 
message from your system.
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Bruce Morton via Servercert-wg]

Entrust votes Yes to ballot SC-067 v3.


Bruce.

From: Servercert-wg  On Behalf Of Chris 
Clements via Servercert-wg
Sent: Monday, July 15, 2024 11:30 AM
To: CA/B Forum Server Certificate WG Public Discussion List 

Subject: [EXTERNAL] [Servercert-wg] Voting Period Begins - Ballot SC-067 V3: 
"Require domain validation and CAA checks to be performed from multiple Network 
Perspectives"

Purpose of Ballot SC-067 V3: 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”). 


Purpose of Ballot SC-067 V3:


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.

- The attached IPR statement has not changed since disclosed in Discussion 
Round 1.

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



- Ballot Release #1 [12] (comparing Version 2 to Version 1) [13]. Note, some of 
the changes represented in the comparison are updates made by other ballots 
that have since passed (e.g., SC-069).

- Ballot Release #2 [14] (comparing Version 3 to Version 2) [15]. Note, some of 
the changes represented in the comparison are updates made by other ballots 
that have since passed (e.g., SC-072).



References:

[1] 
https://cabforum.org/wp-content/uploads/13-CAB-Forum-face-to-face-multiple-vantage-points.pdf

[2] 
https://drive.google.com/file/d/1LTwtAwHXcSaPVSsqKQztNJrV2ozHJ7ZL/view?usp=drive_link

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

[Bruce Morton via Servercert-wg]

Entrust votes No to ballot SC-74.


Bruce.

From: Servercert-wg  On Behalf Of Bruce 
Morton via Servercert-wg
Sent: Monday, May 6, 2024 8:24 AM
To: Dimitris Zacharopoulos (HARICA) ; CA/B Forum Server 
Certificate WG Public Discussion List 
Subject: Re: [Servercert-wg] [EXTERNAL] [Voting Begins] Ballot SC-74 - Clarify 
CP/CPS structure according to RFC 3647

Entrust votes Yes to ballot SC-74. Bruce. From: Servercert-wg 
 On Behalf Of Dimitris Zacharopoulos 
(HARICA) via Servercert-wg Sent: Sunday, May 5, 2024 4: 24 AM To: CA/B Forum 
Server Certificate WG Public

Entrust votes Yes to ballot SC-74.


Bruce.

From: Servercert-wg 
mailto:servercert-wg-boun...@cabforum.org>> 
On Behalf Of Dimitris Zacharopoulos (HARICA) via Servercert-wg
Sent: Sunday, May 5, 2024 4:24 AM
To: CA/B Forum Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org>>
Subject: [EXTERNAL] [Servercert-wg] [Voting Begins] Ballot SC-74 - Clarify 
CP/CPS structure according to RFC 3647

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

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<https://urldefense.com/v3/__https:/lists.cabforum.org/pipermail/servercert-wg/2023-November/004070.html__;!!FJ-Y8qCqXTj2!cKscdErif35z9080I4qUNWiEBkbcvZAU-O348aNPTbBukz2D3MHzp0nkdYntRGQwKmkvU9BasOrNQkRehWXosH6umUupfg$>
 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<https://urldefense.com/v3/__https:/github.com/cabforum/servercert/pull/503__;!!FJ-Y8qCqXTj2!cKscdErif35z9080I4qUNWiEBkbcvZAU-O348aNPTbBukz2D3MHzp0nkdYntRGQwKmkvU9BasOrNQkRehWXosH41qyhIwg$>.

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<https://urldefense.com/v3/__https:/github.com/cabforum/servercert/compare/c4a34fe2292022e0a04ba66b5a85df75907ac2a2...f6a90e2a652fbb7a2d62a976b70f4af3adce8dae__;!!FJ-Y8qCqXTj2!cKscdErif35z9080I4qUNWiEBkbcvZAU-O348aNPTbBukz2D3MHzp0nkdYntRGQwKmkvU9BasOrNQkRehWXosH5EAlr0SA$>

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

Any email and files/attachments transmitted with it are intended solely for the 
use of the individual or entity to whom they are addressed. If this message has 
been sent to you in error, you must not copy, distribute or disclose of the 
information it contains. Please notify Entrust immediately and delete the 
message from your system.
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Bruce Morton via Servercert-wg]

Entrust votes Yes to ballot SC-74.


Bruce.

From: Servercert-wg  On Behalf Of Dimitris 
Zacharopoulos (HARICA) via Servercert-wg
Sent: Sunday, May 5, 2024 4:24 AM
To: CA/B Forum Server Certificate WG Public Discussion List 

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

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

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

Any email and files/attachments transmitted with it are intended solely for the 
use of the individual or entity to whom they are addressed. If this message has 
been sent to you in error, you must not copy, distribute or disclose of the 
information it contains. Please notify Entrust immediately and delete the 
message from your system.
___
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

[Bruce Morton via Servercert-wg]

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 

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 
mailto:wtha...@gmail.com>> 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 
mailto: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 
mailto:bwil...@mozilla.com>> 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 
mailto: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 
mailto:servercert-wg-boun...@cabforum.org>> 
On Behalf Of Dimitris Zacharopoulos (HARICA) via Servercert-wg
Sent: Sunday, April 21, 2024 1:24 AM
To: Aaron Gable mailto:aa...@letsencrypt.org>>; CA/B 
Forum Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org>>
Subject: [EXTERNAL] Re: [Servercert-wg] Discussion Period Begins - Ballot 
SC-071: Subscriber Agreement and Terms of Use Consolidation


On 19/4/2024 9:54 μ.μ., Aaron Gable wrote:
On Fri, Apr 19, 2024 at 11:07 AM Dimitris Zacharopoulos (HARICA) via 
Servercert-wg mailto:servercert-wg@cabforum.org>> 
wrote:
What happens if the SA/ToS document changes? I had the impression that the ACME 
client would be able to see the new version and ask that the updated version is 
accepted. How does this process work in practice

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

[Bruce Morton via Servercert-wg]

Entrust votes Yes to ballot SC-073.


Bruce.

From: Servercert-wg  On Behalf Of Wayne 
Thayer via Servercert-wg
Sent: Thursday, April 25, 2024 8:00 PM
To: CA/B Forum Server Certificate WG Public Discussion List 

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

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


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

Any email and files/attachments transmitted with it are intended solely for the 
use of the individual or entity to whom they are addressed. If this message has 
been sent to you in error, you must not copy, distribute or disclose of the 
information it contains. Please notify Entrust immediately and delete the 
message from your system.
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] [Voting Period Begins]: SC-72 - Delete except to policyQualifiers in EVGs; align with BRs by making them NOT RECOMMENDED

[Bruce Morton via Servercert-wg]

Entrust votes Yes to ballot SC-72.


Bruce.

From: Servercert-wg  On Behalf Of Paul van 
Brouwershaven via Servercert-wg
Sent: Monday, March 25, 2024 8:01 AM
To: CA/B Forum Server Certificate WG Public Discussion List 

Subject: [EXTERNAL] [Servercert-wg] [Voting Period Begins]: SC-72 - Delete 
except to policyQualifiers in EVGs; align with BRs by making them NOT 
RECOMMENDED

This ballot updates the TLS Extended Validation Guidelines (EVGs) by removing 
the exceptions to policyQualifiers​ in section 9. 7, to align them with the 
Baseline Requirements (BRs). The following motion has been proposed by Paul van 
Brouwershaven

This ballot updates the TLS Extended Validation Guidelines (EVGs) by removing 
the exceptions to policyQualifiers​ in section 9.7, to align them with the 
Baseline Requirements (BRs).

The following motion has been proposed by Paul van Brouwershaven (Entrust) and 
endorsed by Dimitris Zacharopoulos (HARICA) and Iñigo Barreira (Sectigo).

--- Motion Begins ---

This ballot modifies the “Guidelines for the Issuance and Management of 
Extended Validation Certificates” (“EV Guidelines”) as follows, based on 
version 1.8.1:

MODIFY the Extended Validation Guidelines as specified in the following 
redline: 
https://github.com/cabforum/servercert/compare/8e7fc7d5cac0cc27c44fe2aa88cf45f5606f4b94...7b9bb1dbfd41b1d0459b8a985ed629ad841ce122

--- Motion Ends ---

Discussion (at least 7 days):
- Start: 2024-03-15 10:00 UTC
- End no earlier than 2024-03-22 10:00 UTC

Vote for approval (7 days):
- Start: 2024-03-25 12:00 UTC
- End: 2024-04-01 12:00 UTC
Any email and files/attachments transmitted with it are intended solely for the 
use of the individual or entity to whom they are addressed. If this message has 
been sent to you in error, you must not copy, distribute or disclose of the 
information it contains. Please notify Entrust immediately and delete the 
message from your system.
___
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

[Bruce Morton via Servercert-wg]

Entrust votes Yes to ballot SC-69v3.


Bruce.

From: Servercert-wg  On Behalf Of Martijn 
Katerbarg via Servercert-wg
Sent: Monday, March 4, 2024 5:59 AM
To: CA/B Forum Server Certificate WG Public Discussion List 

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


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


Any email and files/attachments transmitted with it are intended solely for the 
use of the individual or entity to whom they are addressed. If this message has 
been sent to you in error, you must not copy, distribute or disclose of the 
information it contains. Please notify Entrust immediately and delete the 
message from your system.
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Bruce Morton via Servercert-wg]

Entrust votes Yes to ballot SC65.


Bruce.

From: Servercert-wg  On Behalf Of Inigo 
Barreira via Servercert-wg
Sent: Monday, March 4, 2024 10:34 AM
To: CA/B Forum Server Certificate WG Public Discussion List 

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


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

Any email and files/attachments transmitted with it are intended solely for the 
use of the individual or entity to whom they are addressed. If this message has 
been sent to you in error, you must not copy, distribute or disclose of the 
information it contains. Please notify Entrust immediately and delete the 
message from your system.
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] [EXTERNAL] Re: Compromised/Weak Keys Ballot Proposal

[Bruce Morton via Servercert-wg]

Hi Wayne,

I will endorse this ballot.


Thanks, Bruce.

From: Servercert-wg  On Behalf Of Wayne 
Thayer via Servercert-wg
Sent: Saturday, February 24, 2024 12:38 PM
To: CA/B Forum Server Certificate WG Public Discussion List 

Subject: [EXTERNAL] Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

I think it's safest to err on the side of caution and use the explicit wording 
that you proposed. I've made that clarification in the PR at https: //github. 
com/wthayer/servercert/pull/1/files I'm still seeking a second endorser. 
Thanks,WayneOn

I think it's safest to err on the side of caution and use the explicit wording 
that you proposed.

I've made that clarification in the PR at 
https://github.com/wthayer/servercert/pull/1/files

I'm still seeking a second endorser.

Thanks,

Wayne

On Fri, Feb 23, 2024 at 2:25 PM Tom Zermeno mailto:t...@ssl.com>> 
wrote:
Wayne,

I think it's safest to err on the side of caution and use the explicit wording 
that you proposed.

Thanks,

Tom

From: Wayne Thayer mailto:wtha...@gmail.com>>
Sent: Friday, February 23, 2024 2:45 PM
To: Tom Zermeno mailto:t...@ssl.com>>
Cc: CA/B Forum Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org>>; Martijn 
Katerbarg mailto:martijn.katerb...@sectigo.com>>
Subject: Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

You don't often get email from wtha...@gmail.com. 
Learn why this is 
important
Tom,

I had originally placed the Debian exception in the sublist of 6.1.1.3(5), but 
Aaron Gable correctly pointed out that it doesn't make sense there because that 
sublist is prefaced with the statement "the following precautions SHALL be 
implemented:" I think it would be logically difficult to interpret the 
exception as belonging with 6.1.1.3(5)(ii) Close Primes, but I do agree that it 
could be clearer. To that end, I've change the indentation of the exception 
sentence in 
https://github.com/wthayer/servercert/pull/1/files
 Does that help? I could also change the wording to "Debian weak keys 
(https://wiki.debian.org/SSLkeys)
 are exempt from the requirements of Section 6.1.1.3(5).

Thanks,

Wayne

On Fri, Feb 23, 2024 at 10:33 AM Tom Zermeno 
mailto:t...@ssl.com>> wrote:
Wayne,

Regarding the change of the Debian weak keys statement at proposed line 1701: 
is the statement intended to be a sub-clause of the second item in the sublist, 
which would then make Debian weak keys exempt from the Fermat factorization 
method check?  Or, more likely based on the recent discussion, was the 
statement meant to be a third item in the list, which would then exempt Debian 
weak keys from the 5th condition of the list requiring CAs to reject 
certificate requests?

My question stems from the abnormal line spacing and indention of the 
statement, which stands out from the surrounding text.

Thanks,

Tom

From: Servercert-wg 
mailto:servercert-wg-boun...@cabforum.org>> 
On Behalf Of Wayne Thayer via Servercert-wg
Sent: Friday, February 23, 2024 11:18 AM
To: Martijn Katerbarg 
mailto:martijn.katerb...@sectigo.com>>
Cc: CA/B Forum Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org>>
Subject: Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

Martijn,

I would summarize the reasoning for removing the Debian requirements as follows:
- CAs would prefer the greater clarity that would be provided by the weak keys 
ballot that failed last year.
- However, some CAs were of the opinion that the prior ballot imposed more 
explicit requirements for Debian weak key checking rather than just clarifying 
existing requirements. The "new" requirements were viewed as burdensome.
- The Debian vulnerability is more than 15 years old. If an Applicant submits a 
Debian weak key at this point, they almost certainly have bigger security 
issues.
- So the cost of these requirements outweighs the benefits at this point in 
time.

I included a few links to the discussion during the prior balot's voting 
period, and there was also discussion at the last SCWG teleconference that 
should be captured in the minutes.

Thanks,

Wayne

On Fri, Feb 23, 2024 at 2:19 AM Martijn Katerbarg 
mailto:martijn.katerb...@sectigo.com>> wrote:
Wayne,

Apologies if I’

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

[Bruce Morton via Servercert-wg]

Entrust votes Yes to ballot SC-070.


Bruce.

From: Servercert-wg  On Behalf Of Aaron 
Gable via Servercert-wg
Sent: Tuesday, February 13, 2024 11:57 AM
To: CA/B Forum Server Certificate WG Public Discussion List 

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

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

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
Any email and files/attachments transmitted with it are intended solely for the 
use of the individual or entity to whom they are addressed. If this message has 
been sent to you in error, you must not copy, distribute or disclose of the 
information it contains. Please notify Entrust immediately and delete the 
message from your system.
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] EV Certificates through automation / Pre-Authorized Certificate Approver (API)

[Bruce Morton via Servercert-wg]

Doug,

I do agree that we need to update the EV Guidelines. They were created with the 
theme of single, manual certificate requests. There was no consideration for 
automation. I do think that we should get update understanding of what we want 
out of EV. I agree with "increased verified organizational information/rules", 
which would exclude domains and the functions of a certificate approver and due 
diligence and operations existence ... It should also be certificate type 
neutral, so the EV standard could be applied to any certificate type.


Bruce.

From: Servercert-wg  On Behalf Of Doug 
Beattie via Servercert-wg
Sent: Friday, February 2, 2024 1:43 PM
To: Paul van Brouwershaven ; CA/B Forum 
Server Certificate WG Public Discussion List 
Subject: [EXTERNAL] Re: [Servercert-wg] EV Certificates through automation / 
Pre-Authorized Certificate Approver (API)

Hi Paul,

Yea, that's a lot of good information, but I keep coming back to "what's the 
value of the certificate approver, especially within a managed account, for EV 
in 2024"?  Do we need to have designated individuals as the only people that 
can request EV domains and certificates?  When EVGL was initially written the 
differentiators for EV were much larger than today, and with automation being 
pushed by customers and root programs, can we re-look at this and determine if 
all of the these roles and permissions are still necessary?  If it were up to 
me, I'd make EV issuance the same as OV with the exception of the increased 
verified organizational information/rules so we can standardize and streamline 
TLS EV domain validation and issuance.  We've already aligned the domain 
validation methods and certificate validity periods.

Doug


I get that this certificate has additional details in it, but is the ability to 
bind domains to this request (or identity in the case of a manages service) or 
require that these only be submitted by a specific privileged person still 
relevant?  It's not necessary for OV and am wondering if all of this mapping 
from a designated certificate approver person to API credentials and specific 
roles and permissions is overly complicated

From: Paul van Brouwershaven 
mailto:paul.vanbrouwersha...@entrust.com>>
Sent: Friday, February 2, 2024 10:02 AM
To: Doug Beattie 
mailto:doug.beat...@globalsign.com>>; CA/B Forum 
Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org>>
Subject: Re: EV Certificates through automation / Pre-Authorized Certificate 
Approver (API)

An ACME key and API key are both credentials but just in a different from, I 
provided the examples with API keys as these are most widely used today.

We do indeed use the External Account Binding (EAB), and this works for a setup 
where the user can configure the ACME server at the Cloud Service Provider 
(ACME client) and provide the EAB to the Cloud Service Provider, unfortunately 
this is rarely the case, as I presented at F2F#59 in 
Redmond.

This is why we have been working on an auto discovery mechanism for 
ACME,
 and this works fine for domain validated certificates as you do not need an 
EAB for that, but we would also like to ensure that identity certificates can 
be supported by this proposal.

A domain and organization can be pre-linked at the CA, after verification of 
domain control and the organization identity.

With ACME its simple to validate domain control for each request, this could be 
precondition when there is no explicit and unique account binding. But proving 
domain control does not equal an authorization of a Certificate Approver as 
required for the issuance of an EV certificate.

Like linking an ACME client key via an External Account Binding (EAB) to a 
Pre-Authorized Certificate Approver, according to 11.8.4 of the EVG, to support 
EV certificates over ACME. We could link the ACME keys of an Cloud Service 
Provider at the CA side without EAB if these would be disclosed for linking 
(like via a manual or by publishing them to the well-known directory).

My initial thought is that this would give the same guarantee as when the user 
provides an EAB to the Cloud Service Provider which links that to an ACME 
client key that is shared between all customers as we are just reversing the 
process.

> Do we need the concept of Certificate Approver?
The idea that a human approves individual certificates requests doesn't align 
with the desire for automation.

The concept of a Pre-Authorized certificate approver (EVG 11.8.4) seems to be 
trying to address this issue by allowing multiple future EV Certificate 
Requests.

With API keys linked to Pre-Authorized certificate approvers, we assume that 
all requests made with this API key are on behalf of that Pre-Authorized 
certificate approver, where in reality they are made by a system, which could 
be a th

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

[Bruce Morton via Servercert-wg]

Entrust votes Yes to ballot SC-68.


Bruce.

From: Servercert-wg  On Behalf Of Dimitris 
Zacharopoulos (HARICA) via Servercert-wg
Sent: Tuesday, January 23, 2024 4:00 AM
To: CA/B Forum Server Certificate WG Public Discussion List 

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

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

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

Any email and files/attachments transmitted with it are intended solely for the 
use of the individual or entity to whom they are addressed. If this message has 
been sent to you in error, you must not copy, distribute or disclose of the 
information it contains. Please notify Entrust immediately and delete the 
message from your system.
___
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

[Bruce Morton via Servercert-wg]

I thought an intriguing promise of doing documents in Github and in the same 
format is that we would see the requirements in the same section, which would 
allow for better management. Also, the proposal Paul brought forward for the BR 
of BRs would work much better if we use the same sections. I guess I am 
encouraging the move of EV from a non-standard format to a sort of standard RFC 
3647 format would be to help provide document alignment.

+1 to Dimitris original suggestion.


Thanks, Bruce.

From: Servercert-wg  On Behalf Of Inigo 
Barreira via Servercert-wg
Sent: Monday, December 4, 2023 2:15 PM
To: Dimitris Zacharopoulos (HARICA) ; Tim Hollebeek 

Cc: CA/B Forum Server Certificate WG Public Discussion List 

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

Dimitris, I think that we should focus on the EVG not on the CP/CPS. The CA´s 
CP/CPS will have that 3. 2. 1 section because it´s in the TLS BRs but that does 
not mean that the EVG must have also that section 3. 2. 1 (BTW, the section 
exist in the

Dimitris,

I think that we should focus on the EVG not on the CP/CPS. The CA´s CP/CPS will 
have that 3.2.1 section because it´s in the TLS BRs but that does not mean that 
the EVG must have also that section 3.2.1 (BTW, the section exist in the TLS 
BRs but with no content). At the end of the day, every CA issuing TLS certs 
will have to follow the TLS BRs and EVGs and then accommodate their CP/CPSes 
according to both documents.
I understand your point to be stricter in the implementation of that specific 
point but  for every CA to change/update their current CP/CPS with the new EVG 
in the RFC 3647 format, would find it easier to where to make those 
changes/adjustments in their own CP/CPS if we can convert easily the current 
section 11 into 3.2 and not to start looking into different numbers to make 
that change.

Regards

De: Dimitris Zacharopoulos (HARICA) 
mailto:dzach...@harica.gr>>
Enviado el: lunes, 4 de diciembre de 2023 20:02
Para: Tim Hollebeek 
mailto:tim.holleb...@digicert.com>>; Inigo Barreira 
mailto:inigo.barre...@sectigo.com>>
CC: CA/B Forum Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org>>
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.

FWIW, there are informational RFCs that include SHOULD requirements (I didn't 
check for other informational RFCs that might contain SHALL requirements). Take 
a look at RFC 
8894.

I agree that there seems to be some ambiguity in the REQUIRED CP/CPS structure 
but the entire reasoning behind using the "RFC 3647 format" was to align CP and 
CPS documents so that comparisons can be made across different CAs. If one CA 
reads that they must follow a 2-level structure based on section 4, and another 
CA reads that they must follow the structure of section 6 of the RFC, we're not 
meeting the goal for alignment and easy comparisons.

Digicert's CPS seems to follow the structure of section 6 of RFC 3647. Has 
anyone spotted a CPS claiming compliance with the TLS BRs that is not following 
the section 6 structure of 3647?

If all existing public CAs follow the structure of section 6 of 3647 in their 
CP/CPS documents, we can just clarify that the expectation is what Ben 
mentioned in 
https://github.com/BenWilson-Mozilla/pkipolicy/commit/1a94642cb95017cf382e4e93811db16a2342a806,
 so that we address this ambiguity. We probably don't even need an effective 
date if it causes no issue on existing CAs.

My point is that if we leave this open to interpretation, we can't compare 
CP/CPS sections across multiple CAs efficiently, and this defeats the whole 
purpose of the requirement to structure CP/CPS documents according to RFC 3647. 
We might as well abandon the idea of converting the EV Guidelines into that 
format.

I believe that the intent has always been to enforce a "stricter" alignment. 
But if indeed there are deviations, I'd support some stricter language to align 
CP/CPS documents according to section 6 of RFC 3647 even with a future 
effective date :)


Dimitris.

On 4/12/2023 7:27 μ.μ., Tim Hollebeek wrote:
Yeah, the fact that the section 6 outline goes deeper than the actual described 
format in section 4 is annoying, and you’re right, it’s probably the source of 
these disagreements.  I always look at section 4, because it has the actual 
guidance abou

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

[Bruce Morton via Servercert-wg]

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 proposed by Ben Wilson of Mozilla and Dustin 
Hollenback of Microsoft. And, endorsed by  of  and  of 
.

- 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: 
https://github.com/cabforum/servercert/compare/a0360b61e73476959220dc328e3b68d0224fa0b3..663695b8319c0cd32e0060bb9304ecd32e3737a1

- Motion Ends -


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

Discussion (13+ days)
* Start time: -MM-DD 19:00:00 UTC
* End time: -MM-DD 19:00:00 UTC

Vote for approval (7 days)
* Start time: -MM-DD 19:00:00 UTC
* End time: -MM-DD 19:00:00 UTC


Any email and files/attachments transmitted with it are intended solely for the 
use of the individual or entity to whom they are addressed. If this message has 
been sent to you in error, you must not copy, distribute or disclose of the 
information it contains. Please notify Entrust immediately and delete the 
message from your system.
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Bruce Morton via Servercert-wg]

Hi Ben,

I know we haven’t started the discussion phase, but we have some comments from 
our legal team.

Section 1.6.1, the new Subscriber Agreement definition would narrow 
considerably the defined scope of a Subscriber Agreement. The narrowed scope 
would not accommodate all the BR requirements for what a SA must contain. We 
suggest the following definition “A set of terms and conditions accepted by the 
Applicant/Subscriber that specifies the rights and responsibilities of the 
Applicant/Subscriber and the CA.”

Section 9.6.1, there have been two new warranties added which do not provide 
any value; and the second one may cause confusion and disruption. With respect 
to i., making the most current version of the SA available, all CAs are already 
required to do this by putting the SA into their repository.  With respect to 
ii., it should not matter whether the “applicable” version of the SA happens to 
be the version accepted at the time of issuance. The original warranty in 
9.6.1(5), which is being kept, is the only one that matters, i.e. that there is 
an SA in place that meets the Requirements. As such, we recommend the two new 
proposed warranties be dropped.


Thanks, Bruce.

From: Servercert-wg  On Behalf Of Ben 
Wilson via Servercert-wg
Sent: Wednesday, August 16, 2023 3:46 PM
To: Clint Wilson 
Cc: ServerCert CA/BF 
Subject: [EXTERNAL] Re: [Servercert-wg] SC-XXX: Modify Subscriber Agreement and 
Terms of Use

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"

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 
mailto:cli...@apple.com>> 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 
mailto: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

Any email and files/attachments transmitted with it are intended solely for the 
use of the individual or entity to whom they are addressed. If this message has 
been sent to you in error, you must not copy, distribute or disclose of the 
information it contains. Please notify Entrust immediately and delete the 
message from your system.
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Bruce Morton via Servercert-wg]

Hi Ben,

Thanks for the simplification. I also think the ballot should address the EV 
Guidelines, which also uses both terms. Could you please review?

>From the CAB Forum point of view, I am concerned with this ballot, since I 
>believe the Code Signing and S/MIME BRs use the current terms. This may put 
>the requirements out of sync, which may impact CAs which issue different 
>certificate types. Hopefully the Code Signing and S/MIME working groups will 
>also review and consider addressing these changes if the ballot passes.

We do need to address this type of issue in an overall set of requirements to 
address all certificate types.


Thanks, Bruce.

From: Servercert-wg  On Behalf Of Ben 
Wilson via Servercert-wg
Sent: Monday, August 14, 2023 3:40 PM
To: CA/B Forum Server Certificate WG Public Discussion List 

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

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

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
Any email and files/attachments transmitted with it are intended solely for the 
use of the individual or entity to whom they are addressed. If this message has 
been sent to you in error, you must not copy, distribute or disclose of the 
information it contains. Please notify Entrust immediately and delete the 
message from your system.
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] Notice of Review Period: Ballot SC63 - Make OCSP optional, require CRLs and Incentivize Automation

[Bruce Morton via Servercert-wg]

Agreed.

Bruce.

From: Tim Hollebeek 
Sent: Friday, July 28, 2023 3:33 PM
To: Bruce Morton ; CA/B Forum Server Certificate WG 
Public Discussion List ; Inigo Barreira 

Subject: [EXTERNAL] RE: Notice of Review Period: Ballot SC63 - Make OCSP 
optional, require CRLs and Incentivize Automation

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the 
content is safe.

Just a helpful reminder to everyone trying to comply with this ballot to also 
check the Microsoft Root Program and its requirements around OCSP, which 
haven't changed.

I don't want anyone accidentally running afoul of those program requirements 
because they read the BRs in isolation.

-Tim

From: Servercert-wg 
mailto:servercert-wg-boun...@cabforum.org>> 
On Behalf Of Bruce Morton via Servercert-wg
Sent: Friday, July 28, 2023 9:32 AM
To: Inigo Barreira 
mailto:inigo.barre...@sectigo.com>>; CA/B Forum 
Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org>>
Subject: Re: [Servercert-wg] Notice of Review Period: Ballot SC63 - Make OCSP 
optional, require CRLs and Incentivize Automation

Was just doing an implementation review of this ballot and the "optional" date 
for not supporting OCSP is confusing. Section 4.10.2 states "The CA SHALL 
operate and maintain its CRL and optional OCSP capability with resources 
sufficient to provide a response time of ten seconds or less under normal 
operating conditions." There are no conditions. I will interpret that the 
ballot's intent is that effective 15 March 2024, OCSP is optional and CRL is 
mandatory.

Please advise, if I missed a condition for removal of OCSP in another section.


Thanks, Bruce.

From: Servercert-wg 
mailto:servercert-wg-boun...@cabforum.org>> 
On Behalf Of Inigo Barreira via Servercert-wg
Sent: Monday, July 17, 2023 6:32 AM
To: CA/B Forum Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org>>
Subject: [EXTERNAL] [Servercert-wg] Notice of Review Period: Ballot SC63 - Make 
OCSP optional, require CRLs and Incentivize Automation

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust 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 SC-063 v4: Make OCSP Optional, Require CRLs, and 
Incentivize Automation - CAB 
Forum<https://urldefense.com/v3/__https:/url.avanan.click/v2/___https:/cabforum.org/2023/07/14/ballot-sc-063-v4make-ocsp-optional-require-crls-and-incentivize-automation/___.YXAzOmRpZ2ljZXJ0OmE6bzo1MzJjODcwNzcwNDkxMDdmNDA3ZWY5NzAwMzFmYTQ4Nzo2OjQ4M2E6Zjg1NmVhNjEzNzBiNjM1ZjU2MjliNGJiOWM5Y2NjYzQ3MjkwOTZhYWZkNDE0ZWExY2MxNWU2YjY2MzFkZmRiYjpoOkY__;!!FJ-Y8qCqXTj2!aQNsILvFywxilb1UCK0gielDofnYv72PFhLWnK187fgBTQUpfH_GmAusrLy3A1IJot99ANFTiXJfxmVeWH2yt7P4RI2f$>

Start of Review Period: 17 July 2023 at 17:00 Eastern Time
End of Review Period: 17 August 2023 at 17:00 Eastern Time

Members with any Essential Claim(s) to exclude must forward a written Notice to 
Exclude Essential Claims to the Working Group Chair (email to Iñigo Barreira 
mailto:inigo.barre...@sectigo.com>>) and also 
submit a copy to the CA/B Forum public mailing list (email to public at 
cabforum.org<mailto:public at cabforum.org<mailto:public%20at%20cabforum.org>>) 
before the end of the Review Period.
For details, please see the current version of the CA/Browser Forum 
Intellectual Property Rights 
Policy<https://urldefense.com/v3/__https:/url.avanan.click/v2/___https:/cabforum.org/wp-content/uploads/CABF-IPR-Policy-v.1.3_4APR18.pdf___.YXAzOmRpZ2ljZXJ0OmE6bzo1MzJjODcwNzcwNDkxMDdmNDA3ZWY5NzAwMzFmYTQ4Nzo2OmM5YzA6OTQ3Y2U4YzBjOGI4NWVjNmMxYmZmMjM4ZDQxMmE2ZWY1MTZkODNmOWM2MTIzZTYyNDU5ZjM4MjE4OTgyZjg3NDpoOkY__;!!FJ-Y8qCqXTj2!aQNsILvFywxilb1UCK0gielDofnYv72PFhLWnK187fgBTQUpfH_GmAusrLy3A1IJot99ANFTiXJfxmVeWH2ytx9L45tx$>.
(An optional template for submitting an Exclusion Notice is available at 
https://cabforum.org/wp-content/uploads/Template-for-Exclusion-Notice.pdf<https://urldefense.com/v3/__https:/url.avanan.click/v2/___https:/cabforum.org/wp-content/uploads/Template-for-Exclusion-Notice.pdf___.YXAzOmRpZ2ljZXJ0OmE6bzo1MzJjODcwNzcwNDkxMDdmNDA3ZWY5NzAwMzFmYTQ4Nzo2OmQwODM6NTkxOTlhYTFkYWE0MjJiYzJkNThhOGEzZjk4ZDM1YWE1N2U0MGZkOTBjYWIwMDA3Njk4MTM1N2QwNjgxMGQ1NjpoOkY__;!!FJ-Y8qCqXTj2!aQNsILvFywxilb1UCK0gielDofnYv72PFhLWnK187fgBTQUpfH_GmAusrLy3A1IJot99ANFTiXJfxmVeWH2y

Re: [Servercert-wg] Notice of Review Period: Ballot SC63 - Make OCSP optional, require CRLs and Incentivize Automation

[Bruce Morton via Servercert-wg]

Was just doing an implementation review of this ballot and the "optional" date 
for not supporting OCSP is confusing. Section 4.10.2 states "The CA SHALL 
operate and maintain its CRL and optional OCSP capability with resources 
sufficient to provide a response time of ten seconds or less under normal 
operating conditions." There are no conditions. I will interpret that the 
ballot's intent is that effective 15 March 2024, OCSP is optional and CRL is 
mandatory.

Please advise, if I missed a condition for removal of OCSP in another section.


Thanks, Bruce.

From: Servercert-wg  On Behalf Of Inigo 
Barreira via Servercert-wg
Sent: Monday, July 17, 2023 6:32 AM
To: CA/B Forum Server Certificate WG Public Discussion List 

Subject: [EXTERNAL] [Servercert-wg] Notice of Review Period: Ballot SC63 - Make 
OCSP optional, require CRLs and Incentivize Automation

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust 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 SC-063 v4: Make OCSP Optional, Require CRLs, and 
Incentivize Automation - CAB 
Forum

Start of Review Period: 17 July 2023 at 17:00 Eastern Time
End of Review Period: 17 August 2023 at 17:00 Eastern Time

Members with any Essential Claim(s) to exclude must forward a written Notice to 
Exclude Essential Claims to the Working Group Chair (email to Iñigo Barreira 
mailto:inigo.barre...@sectigo.com>>) and also 
submit a copy to the CA/B Forum public mailing list (email to public at 
cabforum.org>) 
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)
Any email and files/attachments transmitted with it are intended solely for the 
use of the individual or entity to whom they are addressed. If this message has 
been sent to you in error, you must not copy, distribute or disclose of the 
information it contains. Please notify Entrust immediately and delete the 
message from your system.
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg