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

[Mads Egil Henriksveen via Servercert-wg]

Buypass votes NO on ballot SC-74.

Regards
Mads

From: Servercert-wg  On Behalf Of Mads Egil 
Henriksveen via Servercert-wg
Sent: Thursday, May 9, 2024 4:50 PM
To: Dimitris Zacharopoulos (HARICA) ; CA/B Forum Server 
Certificate WG Public Discussion List 
Subject: Re: [Servercert-wg] [Voting Begins] Ballot SC-74 - Clarify CP/CPS 
structure according to RFC 3647

Buypass votes YES on ballot SC-74.

Regards
Mads

From: Servercert-wg 
mailto:servercert-wg-boun...@cabforum.org>> 
On Behalf Of Dimitris Zacharopoulos (HARICA) via Servercert-wg
Sent: Sunday, May 5, 2024 10:25 AM
To: CA/B Forum Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org>>
Subject: [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 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 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

[Fernandez Ruperez, David Alvaro via Servercert-wg]

IZENPE votes NO on 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 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

[hcli]

TWCA changes its vote to “no” on ballot SC-74


Hao-Chun Li


From: Servercert-wg  On Behalf Of 
蔡家宏(chtsai) via Servercert-wg
Sent: Monday, May 6, 2024 4:21 PM
To: Dimitris Zacharopoulos (HARICA) ; CA/B Forum Server 
Certificate WG Public Discussion List 
Subject: Re: [Servercert-wg] [Voting Begins] Ballot SC-74 - Clarify CP/CPS 
structure according to RFC 3647

TWCA votes "yes" to ballot SC-74.


From: Servercert-wg 
mailto:servercert-wg-boun...@cabforum.org>> 
On Behalf Of Dimitris Zacharopoulos (HARICA) via Servercert-wg
Sent: Sunday, May 5, 2024 4:25 PM
To: CA/B Forum Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org>>
Subject: [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 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 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

[陳立群 via Servercert-wg]

Chunghwa Telecom votes "No" to ballot SC-74.


Li-Chun Chen


-Original Message-
From: Servercert-wg  On Behalf Of
Dimitris Zacharopoulos (HARICA) via Servercert-wg
Sent: Friday, May 10, 2024 12:06 AM
To: servercert-wg@cabforum.org
Subject: [外部郵件]Re: [Servercert-wg] [Voting Begins] Ballot SC-74 -
Clarify CP/CPS structure according to RFC 3647

HARICA votes "no" to ballot SC-74.

Dimitris.


On 5/5/2024 12:06 μ.μ., Dimitris Zacharopoulos (HARICA) 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/c4a34fe2292022e0a04ba
66b5a85df75907ac2a2...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 list
Servercert-wg@cabforum.org
 
https://lists.cabforum.org/mailman/listinfo/servercert-wg
 





smime.p7s
Description: S/MIME cryptographic signature
___
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

[大野 文彰 via Servercert-wg]

SECOM Trust Systems changes its vote to NO on Ballot SC-74.

Best Regards,

ONO, Fumiaki
SECOM Trust Systems Co., Ltd.

From: 大野 文彰
Sent: Thursday, May 9, 2024 6:48 PM
To: 'Dimitris Zacharopoulos (HARICA)' ; 'CA/B Forum Server 
Certificate WG Public Discussion List' 
Subject: RE: [Servercert-wg] [Voting Begins] Ballot SC-74 - Clarify CP/CPS 
structure according to RFC 3647

SECOM Trust Systems votes YES on Ballot SC-74.

Best Regards,

ONO, Fumiaki
SECOM Trust Systems Co., Ltd.

From: Servercert-wg [mailto:servercert-wg-boun...@cabforum.org] On Behalf Of 
Dimitris Zacharopoulos (HARICA) via Servercert-wg
Sent: Sunday, May 5, 2024 5:25 PM
To: CA/B Forum Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org>>
Subject: [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 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 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

[Brittany Randall via Servercert-wg]

GoDaddy votes "No" on SC-74 based on the discussion from the Server Certificate 
working group call on May 9. 2024.

Brittany

From: Servercert-wg  on behalf of Dimitris 
Zacharopoulos (HARICA) via Servercert-wg 
Sent: Sunday, May 5, 2024 1:24 AM
To: CA/B Forum Server Certificate WG Public Discussion List 

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

Caution: This email is from an external sender. Please do not click links or 
open attachments unless you recognize the sender and know the content is safe. 
Forward suspicious emails to isitbad@.



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

[Backman, Antti via Servercert-wg]

Telia changes its vote to ’no’ on Ballot SC-74

//Antti


Lähettäjä: Servercert-wg  käyttäjän 
Backman, Antti via Servercert-wg  puolesta
Lähetetty: tiistaina, toukokuuta 7, 2024 8:31 ip.
Vastaanottaja: Dimitris Zacharopoulos (HARICA) ; CA/B Forum 
Server Certificate WG Public Discussion List 
Aihe: Re: [Servercert-wg] [Voting Begins] Ballot SC-74 - Clarify CP/CPS 
structure according to RFC 3647

Telia votes ’Yes’ on Ballot SC-074

//Antti


Lähettäjä: Servercert-wg  käyttäjän 
Dimitris Zacharopoulos (HARICA) via Servercert-wg  
puolesta
Lähetetty: sunnuntaina, toukokuuta 5, 2024 11:24 ap.
Vastaanottaja: CA/B Forum Server Certificate WG Public Discussion List 

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


This email may contain information which is privileged or protected against 
unauthorized disclosure or communication. If you are not the intended 
recipient, please notify the sender and delete this message and any attachments 
from your system without producing, distributing or retaining copies thereof or 
disclosing its contents to any other person.

Telia Company processes emails and other files that may contain personal data 
in accordance with Telia Company’s Privacy 
Policy.


___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Pedro FUENTES via Servercert-wg]

OISTE changes its vote to No, given the latest developments Le 9 mai 2024 à 18:05, Dimitris Zacharopoulos (HARICA) via Servercert-wg  a écrit :

  
  
Based on comments received during -unfortunately- the voting period,
it appears that more attention to detail like the case of the
section headings, punctuation marks, etc need to be carefully
reviewed before approving with this ballot.

I would like to recommend Members to change their vote to "no" so
that the ballot fails and we can re-introduce it after we resolve
these issues.


Thank you,
Dimitris.

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 list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg



  

___Servercert-wg mailing listServercert-wg@cabforum.orghttps://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_servercert-2Dwg=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY=WlMjnLM2C6PyZQPRyPLh2kwB4B2Jq4ST8f6G37E_L98PsUBZYvL9CKYXTr5TZ5bR=GYlSkS34rWaZZQR196WlL7Xzsak_KUXiu44RSQfxUbw=

smime.p7s
Description: S/MIME cryptographic signature
___
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 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

[Marco Schambach via Servercert-wg]

IdenTrust also changes our vote to “No”  on Ballot SC-74 as the feedback from 
others make sense that this ballot requires further finetuning.

 

Marco S.

TrustID Program Manager 

 

From: Servercert-wg  On Behalf Of Marco 
Schambach via Servercert-wg
Sent: Tuesday, May 7, 2024 10:05 AM
To: Dimitris Zacharopoulos (HARICA) ; CA/B Forum Server 
Certificate WG Public Discussion List 
Subject: [Servercert-wg] [Voting Begins] Ballot SC-74 - Clarify CP/CPS 
structure according to RFC 3647

 

IdenTrust votes “Yes” on Ballot SC-74

 

Marco S.

TrustID Program Manager 

 

From: Servercert-wg mailto:servercert-wg-boun...@cabforum.org> > On Behalf Of Dimitris 
Zacharopoulos (HARICA) via Servercert-wg
Sent: Sunday, May 5, 2024 4:25 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 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

 



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

[Servercert-wg] Final minutes of the SCWG call of April 25th

[Inigo Barreira via Servercert-wg]

 

Subject: Final minutes of the SCWG call of April 25th

 

These are the Final Minutes of the Teleconference described in the subject
of this message, prepared by Ryan Dickson (Google Chrome).

 

Server Certificate Working Group Agenda – 25 April 2024

 

 

Attendees: Aaron Poulsen (Amazon Trust Services), Adam Jones (Microsoft),
Andrea Holland (VikingCloud), Ben Wilson (Mozilla), Bindi Davé (DigiCert),
Brianca Martin (Amazon), Chris Clements (Google Chrome), Clint Wilson
(Apple), Corey Bonnell (DigiCert), Corey Rasmussen (OATI), Dimitris
Zacharopoulos (HARICA), Dong Wha Shin (MOIS), Doug Beattie (GlobalSign),
Dustin Hollenback (Microsoft), Enrico Entschew (D-Trust), Gregory Tomko
(GlobalSign), Inaba Atsushi (GlobalSign), Inigo Barreira (Sectigo), Jaime
Hablutzel (OISTE Foundation), Janet Hines (VikingCloud), Jay Wilson
(Sectigo), Johnny Reading (GoDaddy), Keshava Nagaraju (eMudhra), Kiran
Tummala (Microsoft), Li-Chun Chen (Chunghwa Telecom), Lynn Jeun (Visa), Mads
Henriksveen (Buypass AS), Mahua Chaudhuri (Microsoft), Marco Schambach
(IdenTrust), Martijn Katerbarg (Sectigo), Michael Slaughter (Amazon Trust
Services), Miguel Sanchez (Google Trust Services), Mrugesh Chandarana
(IdenTrust), Nargis Mannan (VikingCloud), Nate Smith (GoDaddy), Nicol So
(CommScope), Nome Huang (TrustAsia), Peter Miskovic (Disig), Rollin Yu
(TrustAsia), Ryan Dickson (Google Chrome), Scott Rea (eMudhra), Sissel Hoel
(Buypass), Stephen Davidson (DigiCert), Steven Deitte - (GoDaddy), Tadahiko
Ito (SECOM Trust Systems), Tathan Thacker (IdenTrust), Thomas Zermeno (
 SSL.com), Tim Hollebeek (DigiCert), Trevoli Ponds-White (Amazon
Trust Services), Tsung-Min Kuo (Chunghwa Telecom), Wayne Thayer (Fastly),
Wendy Brown (US Federal PKI Management Authority), Yashwanth TM (eMudhra)

 

Begin Recording and Roll Call

 

The call’s recording was enabled.

 

Inigo greeted participants and opened the meeting.

 

Ryan Dickson is taking minutes.

 

Inigo completed Roll Call (attendees listed above).

 

Read Note-well 

 

Inigo read the Note-well.

 

 

Review Agenda 

 

Inigo reviewed the agenda.

 

No additional agenda items were raised for discussion.

 

Minutes:

 

The following minutes were distributed prior to the call:

 

 

Minutes from February 15th circulated on April 11

 

Minutes from March 28th circulated on April 22

 

Minutes from April 11th circulated on April 18 

 

 

There was no discussion on the above sets of minutes, they are considered
approved.

Inigo will soon publish the approved minutes to the website.

 

Membership:

 

 

N/A - no open requests.

 

 

Issues/topics to discuss

 

Inigo pre-staged three discussion items.

GitHub open issues triage (10 issues per call min): 153, 154, 160, 181, 187,
193, 229, 243, 148 and 252

PAG

F2F agenda

 

Discussion:

 

 

GitHub open issues:

On triage approach: Ping issues twice a year. If no update in six months,
evaluate the issue and determine whether it should be closed,
re-prioritized, or re-assigned. If an issue hasn’t been touched in three
years, it might be closed.

 

 

We discussed the 10 oldest issues:

 

153
 

Update from Corey: Not a high priority, but still should be completed.
Collaboration welcome. 

 

 

Additional discussion: Tim noted this would be an easy “First Ballot" for
someone looking to learn the balloting process. We should consider applying
that label to issues, where appropriate. 

 

 
 154 

Update from Corey: I think this can be closed due to the Profiles Ballot.

Additional discussion: Clint mentioned the only action left, as he recalled,
was verifying the profile ballot addressed the issue. The group discussed
and decided to close the issue, though it can always be reopened if anyone
disagrees.

 

 

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

[Dimitris Zacharopoulos (HARICA) via Servercert-wg]

HARICA votes "no" to ballot SC-74.

Dimitris.

On 5/5/2024 12:06 μ.μ., Dimitris Zacharopoulos (HARICA) 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 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

[Dimitris Zacharopoulos (HARICA) via Servercert-wg]

Based on comments received during -unfortunately- the voting period, it 
appears that more attention to detail like the case of the section 
headings, punctuation marks, etc need to be carefully reviewed before 
approving with this ballot.


I would like to recommend Members to change their vote to "no" so that 
the ballot fails and we can re-introduce it after we resolve these issues.



Thank you,
Dimitris.

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

[Rollin.Yu via Servercert-wg]

TrustAsia votes NO on Ballot SC-74.

Best regards,
Rollin Yu



> On May 5, 2024, at 16: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 list
> Servercert-wg@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg



smime.p7s
Description: S/MIME cryptographic signature
___
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

[Andrea Holland via Servercert-wg]

VikingCloud votes No on SC74.

Regards,
Andrea Holland

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

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


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.

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






Company Registration Details
VikingCloud is the registered business name of Sysxnet Limited. Sysxnet Limited 
is registered in Ireland under company registration number 147176 and its 
registered office is at 1st Floor, Block 71a, The Plaza, Park West Business 
Park, Dublin 12, Ireland.

Email Disclaimer
The information contained in this communication is intended solely for the use 
of the individual or entity to whom it is addressed and others authorized to 
receive it. It may contain confidential or legally privileged information. If 
you are not the intended recipient you are hereby notified that any disclosure, 
copying, distribution or taking any action in reliance on the contents of this 
information is strictly prohibited and may be unlawful. If you have received 
this communication in error, please notify us immediately by responding to this 
email and then delete it from your system. Sysxnet Limited is neither liable 
for the proper and complete transmission of the information contained in this 
communication nor for any delay in its receipt..
___
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

[Scott Rea via Servercert-wg]

eMudhra changes our vote to NO on Ballot SC-74

This is motivated by additional observations enumerated by DigiCert that this 
needs a little more work…

Regards,
_Scott


From: Servercert-wg  on behalf of Dimitris 
Zacharopoulos (HARICA) via Servercert-wg 
Date: Sunday, 5 May 2024 at 2:24 AM
To: CA/B Forum Server Certificate WG Public Discussion List 

Subject: [Servercert-wg] [Voting Begins] Ballot SC-74 - Clarify CP/CPS 
structure according to RFC 3647
CAUTION: This email is originated from outside of the organization. Do not open 
the links or the attachments unless you recognize the sender and know the 
content is safe.

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

Disclaimer: The email and its contents hold confidential information and are 
intended for the person or entity to which it is addressed. If you are not the 
intended recipient, please note that any distribution or copying of this email 
is strictly prohibited as per Company Policy, you are requested to notify the 
sender and delete the email and associated attachments with it from your system.
___
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

[Aaron Gable via Servercert-wg]

At the request of the authors, Let's Encrypt changes our vote on Ballot
SC-74 to No so that the ballot can be modified and resubmitted.

On Tue, May 7, 2024 at 3:21 PM Aaron Gable via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> Let's Encrypt / ISRG votes Yes on Ballot SC-074.
>
> On Sun, May 5, 2024 at 1:24 AM 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 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 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

[Ponds-White, Trev via Servercert-wg]

Amazon Trust Services votes no based on the discussion in the Server Cert group 
call where it was determined we want to make an additional revision to this 
ballot.

From: Servercert-wg  On Behalf Of Dimitris 
Zacharopoulos (HARICA) via Servercert-wg
Sent: Sunday, May 5, 2024 1: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


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


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 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 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
 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] [Voting Begins] Ballot SC-74 - Clarify CP/CPS structure according to RFC 3647

[Doug Beattie via Servercert-wg]

GlobalSign changes our vote to NO on Ballot SC-74.

 

We agree with DigiCert’s observations that this needs a little more work:

The ballot is insufficiently clear about whether punctuation, capitalization, 
etc have to match exactly, and RFC 3647, which is Informative and was never 
intended to be used this way, is inconsistent itself in its use of 
capitalization and punctuation.

 

There needs to be additional clarity about exactly what the requirements are if 
we want to do this.

 

Doug

 

From: Servercert-wg  On Behalf Of Doug 
Beattie via Servercert-wg
Sent: Monday, May 6, 2024 6:41 AM
To: CA/B Forum Server Certificate WG Public Discussion List 

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

 

GlobalSign votes yes on SC-74.

 

Doug

 

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

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

 



smime.p7s
Description: S/MIME cryptographic signature
___
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

[Tim Hollebeek via Servercert-wg]

DigiCert votes NO on Ballot SC-74.



The ballot is insufficiently clear about whether punctuation, capitalization, 
etc have to match exactly, and RFC 3647, which is Informative and was never 
intended to be used this way, is inconsistent itself in its use of 
capitalization and punctuation.



There needs to be additional clarity about exactly what the requirements are 
if we want to do this.



-Tim



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: [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 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://url.avanan.click/v2/___https://github.com/cabforum/servercert/compare/c4a34fe2292022e0a04ba66b5a85df75907ac2a2...f6a90e2a652fbb7a2d62a976b70f4af3adce8dae___.YXAzOmRpZ2ljZXJ0OmE6bzozYzI2MWQxMjUxYTQyZjkzZjc5ZTc2YWM0MDc3NmJhNzo2OmIzOTE6ZDUwNjAwMjUzNmFmM2Y4YzAwNTc2NmVjODkwNWRkYjM4YWY5ODE3NmMzYWI5OTBmOTJkNGZmOWJmODc1MDA4NTp0OkY
 



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





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

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

[Wendy Brown - QT3LB-C via Servercert-wg]

OK - then I have a question for all those voting on SC74 (as an Associate
member rep, I do not have a vote)
How do you interpret the proposed new language:
include at least every section and subsection defined in section 6 of RFC
3647

Does this mean:
a) that the section and subsection headers have to exactly match the text
in RFC 3647 including its use of capitalization, or
b) just that the words must be the same or
c) you just have to have the same numbering and the title can be slightly
different as long as it covers the intended content?

Sorry to not have asked this during the discussion period, until I saw the
output of the linter Aaron prepared, it didn't occur to me that anyone
would have interpreted it as the capitalization had to match.

thanks,

Wendy


Wendy Brown

Supporting GSA

FPKIMA Technical Liaison

Protiviti Government Services
703-965-2990 (cell)


On Thu, May 9, 2024 at 10:33 AM Aaron Gable  wrote:

> I think that is a question to be taken up with the authors of SC-74, and
> with the root programs. In the interest of caution, I think this linting
> tool should err on the side of strictness. It is open source, however, so
> you are of course free to modify it for your own preferences.
>
> Aaron
>
>
> On Thu, May 9, 2024, 04:57 Wendy Brown - QT3LB-C 
> wrote:
>
>> Aaron -
>> Can I suggest that maybe the comparison should be done in a case blind
>> fashion?
>> For example, requiring the headers for the subsections of 1.3 to have the
>> second word lower case when it is common practice to refer to Certification
>> Authorities as CAs and Registration Authorities as RAs, etc. just makes the
>> document inconsistent. I understand the goal is to try to make comparisons
>> easier, but requiring all Public Trusted CAs have these style
>> inconsistencies in their own documentation seems like a step too far.
>>
>> thanks,
>>
>> Wendy
>>
>>
>> Wendy Brown
>>
>> Supporting GSA
>>
>> FPKIMA Technical Liaison
>>
>> Protiviti Government Services
>> 703-965-2990 (cell)
>>
>>
>> On Wed, May 8, 2024 at 6:06 PM Aaron Gable via Servercert-wg <
>> servercert-wg@cabforum.org> wrote:
>>
>>> Of course! Done: https://github.com/cabforum/servercert/issues/513
>>>
>>> On Wed, May 8, 2024 at 8:37 AM Dimitris Zacharopoulos (HARICA) <
>>> dzach...@harica.gr> wrote:
>>>
 Thanks Aaron,

 Would it be ok for you to create a GitHub issue
  to identify the
 specific sections that deviate in content? We might tackle that in a
 cleanup ballot. I don't think the capitalization is so much of a concern
 but if others think it is, please speak up :)


 Dimitris.

 On 8/5/2024 1:19 π.μ., Aaron Gable wrote:

 Two notes on this ballot, findings from our process for handling
 upcoming requirements:

 1) Let's Encrypt has created and open-sourced a tool
  for
 linting a CPS to confirm compliance with RFC 3647 Section 6 and Ballot
 SC-074. If you maintain your CPS document in markdown, it should be very
 simple to use or adapt to your particular situation.

 2) The Baseline Requirements themselves do not quite comply with RFC
 3647 Section 6, with several section titles that deviate from that outline
 in either capitalization or actual content.

 We hope this information is helpful to others,
 Aaron

 On Thu, Apr 25, 2024 at 9:27 AM Dimitris Zacharopoulos (HARICA) via
 Servercert-wg  wrote:

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

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

[Mads Egil Henriksveen via Servercert-wg]

Buypass votes YES on ballot SC-74.

Regards
Mads

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

Subject: [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 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 list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Aaron Gable via Servercert-wg]

I think that is a question to be taken up with the authors of SC-74, and
with the root programs. In the interest of caution, I think this linting
tool should err on the side of strictness. It is open source, however, so
you are of course free to modify it for your own preferences.

Aaron


On Thu, May 9, 2024, 04:57 Wendy Brown - QT3LB-C 
wrote:

> Aaron -
> Can I suggest that maybe the comparison should be done in a case blind
> fashion?
> For example, requiring the headers for the subsections of 1.3 to have the
> second word lower case when it is common practice to refer to Certification
> Authorities as CAs and Registration Authorities as RAs, etc. just makes the
> document inconsistent. I understand the goal is to try to make comparisons
> easier, but requiring all Public Trusted CAs have these style
> inconsistencies in their own documentation seems like a step too far.
>
> thanks,
>
> Wendy
>
>
> Wendy Brown
>
> Supporting GSA
>
> FPKIMA Technical Liaison
>
> Protiviti Government Services
> 703-965-2990 (cell)
>
>
> On Wed, May 8, 2024 at 6:06 PM Aaron Gable via Servercert-wg <
> servercert-wg@cabforum.org> wrote:
>
>> Of course! Done: https://github.com/cabforum/servercert/issues/513
>>
>> On Wed, May 8, 2024 at 8:37 AM Dimitris Zacharopoulos (HARICA) <
>> dzach...@harica.gr> wrote:
>>
>>> Thanks Aaron,
>>>
>>> Would it be ok for you to create a GitHub issue
>>>  to identify the
>>> specific sections that deviate in content? We might tackle that in a
>>> cleanup ballot. I don't think the capitalization is so much of a concern
>>> but if others think it is, please speak up :)
>>>
>>>
>>> Dimitris.
>>>
>>> On 8/5/2024 1:19 π.μ., Aaron Gable wrote:
>>>
>>> Two notes on this ballot, findings from our process for handling
>>> upcoming requirements:
>>>
>>> 1) Let's Encrypt has created and open-sourced a tool
>>>  for
>>> linting a CPS to confirm compliance with RFC 3647 Section 6 and Ballot
>>> SC-074. If you maintain your CPS document in markdown, it should be very
>>> simple to use or adapt to your particular situation.
>>>
>>> 2) The Baseline Requirements themselves do not quite comply with RFC
>>> 3647 Section 6, with several section titles that deviate from that outline
>>> in either capitalization or actual content.
>>>
>>> We hope this information is helpful to others,
>>> Aaron
>>>
>>> On Thu, Apr 25, 2024 at 9:27 AM Dimitris Zacharopoulos (HARICA) via
>>> Servercert-wg  wrote:
>>>

 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: TBD
- End time: TBD


 ___
 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 mailing list
Servercert-wg@cabforum.org

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

[Wendy Brown - QT3LB-C via Servercert-wg]

Aaron -
Can I suggest that maybe the comparison should be done in a case blind
fashion?
For example, requiring the headers for the subsections of 1.3 to have the
second word lower case when it is common practice to refer to Certification
Authorities as CAs and Registration Authorities as RAs, etc. just makes the
document inconsistent. I understand the goal is to try to make comparisons
easier, but requiring all Public Trusted CAs have these style
inconsistencies in their own documentation seems like a step too far.

thanks,

Wendy


Wendy Brown

Supporting GSA

FPKIMA Technical Liaison

Protiviti Government Services
703-965-2990 (cell)


On Wed, May 8, 2024 at 6:06 PM Aaron Gable via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> Of course! Done: https://github.com/cabforum/servercert/issues/513
>
> On Wed, May 8, 2024 at 8:37 AM Dimitris Zacharopoulos (HARICA) <
> dzach...@harica.gr> wrote:
>
>> Thanks Aaron,
>>
>> Would it be ok for you to create a GitHub issue
>>  to identify the specific
>> sections that deviate in content? We might tackle that in a cleanup ballot.
>> I don't think the capitalization is so much of a concern but if others
>> think it is, please speak up :)
>>
>>
>> Dimitris.
>>
>> On 8/5/2024 1:19 π.μ., Aaron Gable wrote:
>>
>> Two notes on this ballot, findings from our process for handling upcoming
>> requirements:
>>
>> 1) Let's Encrypt has created and open-sourced a tool
>>  for
>> linting a CPS to confirm compliance with RFC 3647 Section 6 and Ballot
>> SC-074. If you maintain your CPS document in markdown, it should be very
>> simple to use or adapt to your particular situation.
>>
>> 2) The Baseline Requirements themselves do not quite comply with RFC 3647
>> Section 6, with several section titles that deviate from that outline in
>> either capitalization or actual content.
>>
>> We hope this information is helpful to others,
>> Aaron
>>
>> On Thu, Apr 25, 2024 at 9:27 AM Dimitris Zacharopoulos (HARICA) via
>> Servercert-wg  wrote:
>>
>>>
>>> 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: TBD
>>>- End time: TBD
>>>
>>>
>>> ___
>>> 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 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

[大野 文彰 via Servercert-wg]

SECOM Trust Systems votes YES on Ballot SC-74.

Best Regards,

ONO, Fumiaki
SECOM Trust Systems Co., Ltd.

From: Servercert-wg [mailto:servercert-wg-boun...@cabforum.org] On Behalf Of 
Dimitris Zacharopoulos (HARICA) via Servercert-wg
Sent: Sunday, May 5, 2024 5:25 PM
To: CA/B Forum Server Certificate WG Public Discussion List 

Subject: [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 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 list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg