Re: [cabfpub] Voting Period Begins: Ballot FORUM-022: Establish Forum IPR Subcommittee

2024-05-17 Thread Clint Wilson via Public
Apple votes YES on FORUM-022.

> On May 15, 2024, at 8:01 AM, Ben Wilson via Public  
> wrote:
> 
> Ballot FORUM-022:  Establish Forum IPR Subcommittee
>  
> Proposed by Ben Wilson of Mozilla and endorsed by Roman Fischer of SwissSign 
> and Clint Wilson of Apple.
>  
> Purpose of Ballot
>  
> The CA/Browser Forum’s Intellectual Property Rights (IPR) Policy and 
> associated documentation were last revised in 2018. Since then, there have 
> been requests for clarification about application of the IPR Policy to 
> contributions of non-Forum Members, and sections of the IPR Policy and 
> documentation have been identified as needing amendment, including the form 
> for filing and handling of Essential Claim Exclusion Notices. It is proposed 
> that a Charter be adopted establishing a Forum IPR Subcommittee (FIPR) and 
> that the proposed scope of the FIPR be to update and improve the IPR Policy 
> and associated documentation and to discuss the following:
>  
> (a) How to address contributions provided by non-Forum Members (e.g., invited 
> experts, guest speakers, researchers, etc.);
> (b) If any clarifications and/or changes are necessary to the IPR Policy in 
> view of recent events; and
> (c) A potential contributor license agreement for the Forum’s GitHub 
> repository and policy for contributing to the Forum’s GitHub repository.
>  
> Following the passage of this ballot:
> A new Forum IPR Subcommittee will be formed under the CA/Browser Forum, as 
> outlined in section 5.6 of the Bylaws (Forum Subcommittees);
> Mailing list(s), GitHub repository(ies), Wiki resource(s), and other 
> collaboration tools will be established as needed to enable the Forum 
> Subcommittee to fulfill its charter; and
> The Forum Subcommittee will publish a set of recommended revisions to the IPR 
> Policy and associated documentation for the Forum to adopt.
>  
> MOTION BEGINS
>  
> Establish Forum IPR Subcommittee
>  
> Upon approval from the CA/Browser Forum by ballot in accordance with sections 
> 2.3 and 5.6 of the Forum Bylaws, the Forum IPR Subcommittee (“FIPR”) is 
> created to perform the activities as specified in the Charter, which is found 
> here: 
>  
> https://github.com/cabforum/forum/compare/30de00ae9672088cf618706b9e7c464fa8c34c51...b50bc495ced317c437ed6b397bb4fb574484b56b
>  
> MOTION ENDS
>  
> The procedure for approval of this ballot is as follows:
>  
> Discussion (7+ days)
>  
> Start Time: 2024-May-06 22:00 UTC
> End Time: After 2024-May-13 22:00 UTC
>  
> Vote for approval (7 days)
>  
> Start Time:  2024-May-15 15:00 UTC
> End Time:  2024-May-22 15:00 UTC
>  
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public


Re: [cabfpub] CABG: Follow-up actions to the creation of the new Definitions and Glossary Working Group

2024-04-24 Thread Clint Wilson via Public
Apple would like to participate in the Definitions and Glossary Working Group 
(DGWG).

> On Apr 22, 2024, at 9:27 AM, Dimitris Zacharopoulos (HARICA) via Public 
>  wrote:
>
>
> Dear Members,
>
> I have added the approved Charter of the Definitions and Glossary Working 
> Group (DGWG) to the main GitHub Forum repository 
> https://github.com/cabforum/forum/blob/main/DGWG-Charter.md.
>
> I welcome Tim Hollebeek (Chair) and Tim Callan (Vice-Chair) to coordinate 
> with the Infrastructure Subcommittee to create the necessary mailing lists, 
> area in the cabforum.org Public Website and possibly a separate area in the 
> Member's Website (wiki.cabforum.org).
>
> According to the Bylaws and IPR Policy, each Member must declare its 
> participation to the DGWG, preferably by replying to this email so the 
> declaration can be registered on the Public Mailing List.
>
>
> Best regards,
>
> Dimitris Zacharopoulos
> CA/B Forum Chair
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public


Re: [cabfpub] Draft Charter for IPR Subcommittee

2024-04-18 Thread Clint Wilson via Public
Hi Ben,

We’re very supportive of chartering this Subcommittee. We’re still reviewing 
and may have some further feedback, but I expect once we’ve completed that we’d 
be able to endorse if needed.

Cheers,
-Clint

> On Apr 18, 2024, at 8:37 AM, Ben Wilson via Public  
> wrote:
> 
> All,
> I will put this in ballot format. I am looking for endorsers.
> Thanks,
> Ben
> 
> On Tue, Apr 16, 2024 at 10:48 AM Ben Wilson  > wrote:
>> All,
>> 
>> As mentioned during the Forum teleconference of April 11, 2024, here is a 
>> draft charter for a Forum IPR Subcommittee. (This effort is separate, but 
>> somewhat in parallel to the work of the Patent Advisory Group, which will be 
>> handling GoDaddy's Patent Exclusion Notice, filed Mar. 22, 2024, in relation 
>> to Ballot SC-70.) 
>> 
>> Please provide your comments or questions.
>> 
>> Thanks,
>> 
>> Ben
>> 
>>  
>> 
>> Forum IPR Subcommittee Charter
>> 
>> Upon approval of the CAB Forum by ballot in accordance with section 5.6 of 
>> the Bylaws, the Forum IPR Subcommittee (“FIS”) is created to perform the 
>> activities as specified in this Charter, subject to the terms and conditions 
>> of the CA/Browser Forum Bylaws and Intellectual Property Rights (IPR) 
>> Policy, as such documents may change from time to time. The definitions 
>> found in the Forum’s Bylaws or IPR Policy shall apply to capitalized terms 
>> in this Charter.
>> 
>> Scope
>> 
>> The primary activity of the FIS shall be to review, and propose revisions 
>> to, the Forum’s IPR Policy, IPR Policy Agreement, exclusion notice template, 
>> and similar documents.  The FIS may perform other activities ancillary to 
>> this primary activity.  The FIS will not create Final Guidelines or Final 
>> Maintenance Guidelines.
>> 
>> Anticipated End Date
>> 
>> The FIS is chartered without a specific end date. However, it is expected 
>> that the FIS will deliver results of its initial work to the Forum prior to 
>> _ 2024.  Thereafter, the FIS will continue to exist, but may be 
>> dissolved at any time by Forum ballot.
>> 
>> Initial Chairs and Contacts
>> 
>> The proposer of the ballot adopting this Charter, Ben Wilson, will act as 
>> organizer of the FIS until the first teleconference is held for the FIS, at 
>> which time the FIS will elect a chair and vice-chair, either by vote or by 
>> acclamation of those present. The chair and vice-chair will normally serve 
>> two-year terms.  However, the first term will start upon their election and 
>> run through 31 October 2026.
>> 
>> Members Eligible to Participate
>> 
>> The FIS welcomes the participation of any Member organization of the Forum 
>> interested in this work.  Forum Members that have initially declared their 
>> participation in this Subcommittee are:
>> 
>> Amazon, Apple, DigiCert, GoDaddy, Google, HARICA, Let’s Encrypt, Mozilla, 
>> Sectigo, SwissSign,
>> 
>> Voting and Voting Structure
>> 
>> Voting in the FIS shall be limited to Forum members. Voting shall be 
>> egalitarian: all Members shall vote together as a single class, with one 
>> vote granted to each Member organization. Any decisions of the FIS needed to 
>> be voted upon by the FIS shall be considered adopted if the number of votes 
>> in favor exceeds 50% of the votes cast.
>> 
>> Primary Means of Communication
>> 
>> The FIS will communicate primarily through listserv-based email and shall 
>> conduct periodic calls or face-to-face meetings as needed.
>> 
>> 
>> 
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public


Re: [cabfpub] Voting Period Begins | Ballot FORUM-021: Form Definitions and Glossary WG

2024-04-08 Thread Clint Wilson via Public
Apple votes YES on Ballot FORUM-021

> On Apr 4, 2024, at 8:03 AM, Clint Wilson via Public  
> wrote:
> 
> Ballot FORUM-021
> 
> Proposed by Clint Wilson of Apple and endorsed by Tim Hollebeek of DigiCert 
> and Tim Callan of Sectigo.
> 
> Purpose of Ballot
> 
> The CA/Browser Forum publishes Final Guidelines representing technical 
> requirements about nuanced and challenging PKI implementations. It is 
> proposed that the establishment of a Definitions and Glossary Working Group 
> will assist the Forum as a whole, and its individual Chartered Working 
> Groups, in the following ways:
> 
> 1. Clarity and Consistency: Standardizing the definitions of terms will help 
> Members and other interested parties have a clearer understanding of the 
> terminology being used. This should reduce ambiguity and confusion, while 
> increasing consistency in interpretation and use across Working Groups and 
> Final Guidelines.
> 2. Effective Communication: A Glossary enables more effective communication 
> among Members, as well as with external stakeholders such as industry 
> partners, regulatory bodies, and other standardization organizations. It 
> helps to ensure that everyone involved in the process is speaking the same 
> language and, as such, may have a positive impact beyond the Forum alone.
> 3. Quality: By establishing a Glossary, the Forum can focus efforts on 
> enhancing the quality and accuracy of the language used in published 
> Guidelines. The availability of consistent, high-quality terminology reduces 
> the risk of misunderstandings, errors, and misinterpretations that could 
> undermine the effectiveness of the Forum.
> 4. Accessibility and Learning: For new Members or observers of the Forum, 
> having a centralized Glossary provides a valuable resource for learning the 
> specialized terminology used here. As with Guidelines in general, a focused 
> Glossary can reduce the learning curve associated with understanding, 
> implementing, and complying with complex baseline requirements documents.
> 5. Cross-referencing and Interoperability: A well-defined Glossary 
> facilitates cross-referencing between Guidelines and promotes 
> interoperability between the Forum’s Chartered Working Groups as well as 
> external systems, products, processes, and people that rely on mutual 
> understanding of shared terminology. 
> 6. Feedback and Iterative Improvement: Building and maintaining a Glossary 
> provides a framework for soliciting and receiving feedback from industry 
> stakeholders and continuously improving the clarity and accuracy of the 
> definitions over time. As new terms emerge or existing definitions evolve, 
> the Glossary can be updated, ensuring that the Forum remains current and 
> responsive to industry changes.
> 
> Following the passage of this ballot:
> 
> A new Definitions and Glossary Chartered Working Group will be formed under 
> the CA/Browser Forum, as outlined in section 5.3.1 of the Bylaws;
> A Mailing list(s), GitHub repository(ies), and Wiki resource(s) will be 
> established as needed to enable the D WG to fulfill its charter;
> The D WG will collaborate with other CWGs in the Forum as stipulated in the 
> charter found below; and
> The D WG will produce and maintain a Glossary document.
> 
> MOTION BEGINS
> 
> Establish Definitions and Glossary Working Group
> 
> Upon approval from the CA/Browser Forum by ballot in accordance with section 
> 5.3 of the Forum Bylaws, the Definitions and Glossary Working Group (“DGWG”) 
> is created to perform the activities as specified in the Charter as found 
> here: 
> https://github.com/cabforum/forum/compare/9805b6976e7a7ac391048d4eadb4379aa956110b...2b2b081a224031050aedf9404d9ce50344a468e8
> 
> MOTION ENDS
> 
> The procedure for approval of this ballot is as follows:
> 
> Discussion (7+ days)
> 
> Start Time: 2024-Mar-21 15:00 UTC
> End Time: 2024-April-4 14:59 UTC
> 
> Vote for approval (7 days)
> 
> Start Time: 2024-April-4 15:00 UTC
> End Time: 2024-April-11 15:00 UTC
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public


[cabfpub] Voting Period Begins | Ballot FORUM-021: Form Definitions and Glossary WG

2024-04-04 Thread Clint Wilson via Public
Ballot FORUM-021

Proposed by Clint Wilson of Apple and endorsed by Tim Hollebeek of DigiCert and 
Tim Callan of Sectigo.

Purpose of Ballot

The CA/Browser Forum publishes Final Guidelines representing technical 
requirements about nuanced and challenging PKI implementations. It is proposed 
that the establishment of a Definitions and Glossary Working Group will assist 
the Forum as a whole, and its individual Chartered Working Groups, in the 
following ways:

1. Clarity and Consistency: Standardizing the definitions of terms will help 
Members and other interested parties have a clearer understanding of the 
terminology being used. This should reduce ambiguity and confusion, while 
increasing consistency in interpretation and use across Working Groups and 
Final Guidelines.
2. Effective Communication: A Glossary enables more effective communication 
among Members, as well as with external stakeholders such as industry partners, 
regulatory bodies, and other standardization organizations. It helps to ensure 
that everyone involved in the process is speaking the same language and, as 
such, may have a positive impact beyond the Forum alone.
3. Quality: By establishing a Glossary, the Forum can focus efforts on 
enhancing the quality and accuracy of the language used in published 
Guidelines. The availability of consistent, high-quality terminology reduces 
the risk of misunderstandings, errors, and misinterpretations that could 
undermine the effectiveness of the Forum.
4. Accessibility and Learning: For new Members or observers of the Forum, 
having a centralized Glossary provides a valuable resource for learning the 
specialized terminology used here. As with Guidelines in general, a focused 
Glossary can reduce the learning curve associated with understanding, 
implementing, and complying with complex baseline requirements documents.
5. Cross-referencing and Interoperability: A well-defined Glossary facilitates 
cross-referencing between Guidelines and promotes interoperability between the 
Forum’s Chartered Working Groups as well as external systems, products, 
processes, and people that rely on mutual understanding of shared terminology. 
6. Feedback and Iterative Improvement: Building and maintaining a Glossary 
provides a framework for soliciting and receiving feedback from industry 
stakeholders and continuously improving the clarity and accuracy of the 
definitions over time. As new terms emerge or existing definitions evolve, the 
Glossary can be updated, ensuring that the Forum remains current and responsive 
to industry changes.

Following the passage of this ballot:

A new Definitions and Glossary Chartered Working Group will be formed under the 
CA/Browser Forum, as outlined in section 5.3.1 of the Bylaws;
A Mailing list(s), GitHub repository(ies), and Wiki resource(s) will be 
established as needed to enable the D WG to fulfill its charter;
The D WG will collaborate with other CWGs in the Forum as stipulated in the 
charter found below; and
The D WG will produce and maintain a Glossary document.

MOTION BEGINS

Establish Definitions and Glossary Working Group

Upon approval from the CA/Browser Forum by ballot in accordance with section 
5.3 of the Forum Bylaws, the Definitions and Glossary Working Group (“DGWG”) is 
created to perform the activities as specified in the Charter as found here: 
https://github.com/cabforum/forum/compare/9805b6976e7a7ac391048d4eadb4379aa956110b...2b2b081a224031050aedf9404d9ce50344a468e8

MOTION ENDS

The procedure for approval of this ballot is as follows:

Discussion (7+ days)

Start Time: 2024-Mar-21 15:00 UTC
End Time: 2024-April-4 14:59 UTC

Vote for approval (7 days)

Start Time: 2024-April-4 15:00 UTC
End Time: 2024-April-11 15:00 UTC

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public


[cabfpub] Discussion Period Begins | Ballot FORUM-021: Form Definitions and Glossary WG

2024-03-21 Thread Clint Wilson via Public
Ballot FORUM-021

Proposed by Clint Wilson of Apple and endorsed by Tim Hollebeek of DigiCert and 
Tim Callan of Sectigo.

Purpose of Ballot

The CA/Browser Forum publishes Final Guidelines representing technical 
requirements about nuanced and challenging PKI implementations. It is proposed 
that the establishment of a Definitions and Glossary Working Group will assist 
the Forum as a whole, and its individual Chartered Working Groups, in the 
following ways:

1. Clarity and Consistency: Standardizing the definitions of terms will help 
Members and other interested parties have a clearer understanding of the 
terminology being used. This should reduce ambiguity and confusion, while 
increasing consistency in interpretation and use across Working Groups and 
Final Guidelines.
2. Effective Communication: A Glossary enables more effective communication 
among Members, as well as with external stakeholders such as industry partners, 
regulatory bodies, and other standardization organizations. It helps to ensure 
that everyone involved in the process is speaking the same language and, as 
such, may have a positive impact beyond the Forum alone.
3. Quality: By establishing a Glossary, the Forum can focus efforts on 
enhancing the quality and accuracy of the language used in published 
Guidelines. The availability of consistent, high-quality terminology reduces 
the risk of misunderstandings, errors, and misinterpretations that could 
undermine the effectiveness of the Forum.
4. Accessibility and Learning: For new Members or observers of the Forum, 
having a centralized Glossary provides a valuable resource for learning the 
specialized terminology used here. As with Guidelines in general, a focused 
Glossary can reduce the learning curve associated with understanding, 
implementing, and complying with complex baseline requirements documents.
5. Cross-referencing and Interoperability: A well-defined Glossary facilitates 
cross-referencing between Guidelines and promotes interoperability between the 
Forum’s Chartered Working Groups as well as external systems, products, 
processes, and people that rely on mutual understanding of shared terminology. 
6. Feedback and Iterative Improvement: Building and maintaining a Glossary 
provides a framework for soliciting and receiving feedback from industry 
stakeholders and continuously improving the clarity and accuracy of the 
definitions over time. As new terms emerge or existing definitions evolve, the 
Glossary can be updated, ensuring that the Forum remains current and responsive 
to industry changes.

Following the passage of this ballot:

A new Definitions and Glossary Chartered Working Group will be formed under the 
CA/Browser Forum, as outlined in section 5.3.1 of the Bylaws;
A Mailing list(s), GitHub repository(ies), and Wiki resource(s) will be 
established as needed to enable the D WG to fulfill its charter;
The D WG will collaborate with other CWGs in the Forum as stipulated in the 
charter found below; and
The D WG will produce and maintain a Glossary document.

MOTION BEGINS

Establish Definitions and Glossary Working Group

Upon approval from the CA/Browser Forum by ballot in accordance with section 
5.3 of the Forum Bylaws, the Definitions and Glossary Working Group (“DGWG”) is 
created to perform the activities as specified in the Charter as found here: 
https://github.com/cabforum/forum/compare/9805b6976e7a7ac391048d4eadb4379aa956110b...2b2b081a224031050aedf9404d9ce50344a468e8

MOTION ENDS

The procedure for approval of this ballot is as follows:

Discussion (7+ days)

Start Time: 2024-Mar-21 15:00 UTC
End Time: After 2024-Mar-28 15:00 UTC

Vote for approval (7 days)

Start Time: TBD
End Time: TBD

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public


Re: [cabfpub] Ballot FORUM-019 v.2 - Amend Server Certificate Working Group Charter - VOTING PERIOD

2023-11-30 Thread Clint Wilson via Public
Apple votes YES on Ballot FORUM-019 v.2

> On Nov 27, 2023, at 7:44 AM, Ben Wilson via Public  
> wrote:
> 
> The voting period for Ballot FORUM-019 v.2 starts today. Votes must be cast 
> on the Forum public list in accordance with the Forum's Bylaws.  Voting will 
> conclude at 16:00 UTC on 4 December 2023.
> 
> Ballot FORUM-019 v.2 - Amend Server Certificate Working Group Charter
> 
> Purpose of Ballot
> 
> This ballot proposes to amend the Server Certificate Working Group (SCWG) 
> Charter, based on existing version 1.2 of the Charter and on recent updates 
> to the Forum’s Bylaws.
> 
> During discussions at Face-to-Face Meeting 58, it was noted that the 
> membership criteria for Certificate Consumers in the SCWG Charter lacked 
> sufficient detail. Since then, through discussions on the mailing list of the 
> SCWG and elsewhere, better criteria for membership of Certificate Consumers 
> in the SCWG have been developed, and the ballot also adds a 6-month 
> probationary period for all applicants to the SCWG before they become voting 
> members.
> 
> Additionally, section numbering has been added, the outdated "Root 
> Certificate Issuer" voting category has been removed, and provisions 
> regarding voting percentages and quorum have been clarified.
> 
> The following motion has been proposed by Ben Wilson of Mozilla and endorsed 
> by Martijn Katerbarg of Sectigo and Dimitris Zacharopoulos of HARICA.
> 
> 
> 
> - Motion Begins -
> 
> MODIFY the Charter of the Server Certificate Working Group as specified in 
> the following redline:
> 
> https://github.com/cabforum/forum/compare/59185f16917cc7f5b83564fe5fddff32cf84c8ce...3af42d2d9e38a0dfcdf9450d5ca772365d5b5dbb
> 
> 
> 
> 
> 
> - Motion Ends -
> 
> 
> 
> This ballot does not propose a Final Guideline or Final Maintenance 
> Guideline. 
> 
> The procedure for approval of this ballot is as follows:
> 
> Discussion Period (7+ days)
> 
> Start Time: 2023-11-16  23:00 UTC
> 
> End Time: Not before 2023-11-23  23:00 UTC
> 
>  
> Vote for approval (7 days)
> 
> Start Time: 2023-11-27  16:00 UTC
> 
> End Time:  2023-12-04  16:00 UTC
> 
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public


Re: [cabfpub] Voting begins for Ballot Forum-18 v3 - Update CA/B Forum Bylaws to version 2.5

2023-07-19 Thread Clint Wilson via Public
Apple votes Yes on Forum-018.

> On Jul 13, 2023, at 1:43 AM, Dimitris Zacharopoulos (HARICA) via Public 
>  wrote:
> 
> This message begins the voting period for ballot Forum-18 v3.
> 
> Dimitris.
> 
> Purpose of the Ballot
> 
> The Forum has identified and discussed a number of improvements to be made to 
> the current version of the Bylaws to improve clarity and allow the Forum to 
> function more efficiently. Most of these changes are described in the “Issues 
> with Bylaws to be addressed 
> ”
>  document. Some preparatory discussions and reviews can be checked on GitHub 
> .
> Here is a list of major changes:
> 
> Clarified that it is not always required to “READ” the antitrust statement 
> before each meeting and added the option of reading a "note-well".
> Clarified where to send/post Chartered Working Group minutes.
> Increased the number of days before automatic failing a ballot from 21 to 90 
> days.
> Allow Chair or Vice-Chair to update links to other sections within a document 
> without a ballot.
> Applied grammatical and other language improvements.
> Clarified that Subcommittee minutes do not need to also be published on the 
> public web site.
> Created a new member category called "Probationary Member", applicable to 
> both Certificate Issuer and Consumer categories, and separated "Associate 
> Members - Certificate Issuers" from the "Associate Member" category.
> Clarified language for Associate Members for consistency with Probationary 
> Member for the ballot proposals and endorsing.
> Removed the member category called "Root CA Issuer" and only kept the "CA 
> Issuer" category.
> Added a step to check the authority of the signer during membership 
> applications.
> Updated the Chartered Working Group template.
> Added some language to the Code of Conduct.
> Publishing private conversations without express permission is considered a 
> violation of the Code of Conduct.
> Updated the elections language as agreed at F2F#58.
> The following motion has been proposed by Dimitris Zacharopoulos of HARICA 
> and endorsed by Ben Wilson of Mozilla and Paul van Brouwershaven of Entrust.
> 
> MOTION BEGINS
> 
> Amendment to the Bylaws: Replace the entire text of the Bylaws of the 
> CA/Browser Forum with the attached version (CA-Browser Forum Bylaws v2.5.pdf).
> NOTE: There are two redlines produced by GitHub
> 
> Bylaws-redline.pdf (attached)
> GitHub redline available at 
> https://github.com/cabforum/forum/pull/32/files#diff- 
> 3c3a1aa55886ff217ac9c808f96a5e9a9582fc11
>  
> 
> MOTION ENDS
> 
> The procedure for this ballot is as follows:
> 
> Forum-18 v3 - Update CA/B Forum Bylaws to version 2.5
> Start time (10:00 UTC)End time (10:00 UTC)
> Discussion (at least 7 days)  4 July 2023 11 July 2023
> Expected Vote for approval (7 days)   13 July 2023
> 20 July 2023
>  v2.5.pdf>___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public


Re: [cabfpub] Voting Begins: FORUM-18, Allow Re-election of CWG Chairs and Vice Chairs

2022-08-02 Thread Clint Wilson via Public
Apple votes YES on FORUM-18.

> On Jul 27, 2022, at 12:10 PM, Tim Hollebeek via Public  
> wrote:
> 
> — MOTION BEGINS —
>  
> The Bylaws of the CA/Browser Forum are amended as described in the following 
> redline:
>  
> https://github.com/cabforum/forum/compare/fa1a5cb37a452e53d769ed759c06f05d21b1cb4b..f197d28fac92c807896d55b6ef43b776b6264aca
>  
> 
>  
> — MOTION ENDS —



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public


Re: [cabfpub] Draft Working Group Charter for Network Security WG

2021-11-11 Thread Clint Wilson via Public
FWIW, I think we need to be careful about discussing IPR policy implications 
without references to the relevant part of the IPR policy, which governs here. 
The policy, as I understand it, only obligates WG participants to IPR 
obligations. The implications of various approaches vary widely (and as both 
Tim and Dimitris have pointed out, in problematic directions in some cases). 
Perhaps taking a step back and outlining the goals of the re-charter more 
explicitly will help us better map potential engagement models and identify 
issues that need to be resolved as well.

> On Nov 11, 2021, at 8:30 AM, Dimitris Zacharopoulos (HARICA) via Public 
>  wrote:
> 
> 
> 
> On 11/11/2021 5:56 μ.μ., Tim Hollebeek wrote:
>> I don’t think it can be done.  Remember, the entire point of various people 
>> not being in various working groups is because they don’t want to review, 
>> disclose, or grant licenses based on updates to the documents in that 
>> working group.
>>  
>> While it would be nice if everyone joined the NetSec working group, so that 
>> we’re sure that the NCSSRs are free from IPR encumbrances, I don’t think we 
>> can force everyone to do so.  Which is essentially what you’d be doing by 
>> expanding IPR review to all the CWGs.
> 
> If the IP review notice was sent out to all working groups, Members of all 
> WGs would need to review and send any notices to the Chair that started the 
> Review period, according to the Bylaws in section 2.4-6.
> 
> Wouldn't this process work? This process is still not enforcing all Working 
> Groups to adopt the updated Guideline, it just completes the IP Review phase 
> in the NetSec WG in a more effective/efficient way.
> 
> 
> Dimitris.
> 
>>  
>> -Tim
>>  
>> From: Ben Wilson   
>> Sent: Wednesday, November 10, 2021 10:31 AM
>> To: Dimitris Zacharopoulos  
>> Cc: CABforum1  ; Tim 
>> Hollebeek  
>> Subject: Re: [cabfpub] Draft Working Group Charter for Network Security WG
>>  
>> I can add your first point into the ballot.
>>  
>> Does anyone have any language that would address Dimitris' second point, 
>> about enforcement across the board for the entire CAB Forum? We don't want 
>> to have to track different versions among Working Groups.
>>  
>> Thanks,
>>  
>> Ben
>>  
>> On Tue, Nov 9, 2021, 11:36 PM Dimitris Zacharopoulos > > wrote:
>> Ben, 
>> 
>> To minimize the risk of including IP protected material in the NetSec 
>> Guidelines, I propose that the IPR review process includes all Chartered 
>> Working Groups. Exclusion notices might arrive by any Member of any CWG. 
>> 
>> At the same time, all CWG members will be aware of changes in the NetSec WG 
>> Guidelines because they would need to check for IPR issues. 
>> 
>> Thoughts about that? 
>> 
>> On the updated language and "enforcement" of updated NetSec Guidelines to 
>> other Working Groups, I'm afraid it is not allowed. Chartered Working Groups 
>> have the necessary isolation from the Bylaws so that one CWG doesn't affect 
>> the work of another CWG, so I'm afraid this language is inconsistent with 
>> the current Bylaws. 
>> 
>> 
>> Dimitris.
>>  
>> Nov 10, 2021 05:20:40 Ben Wilson via Public > >:
>> 
>> Here is another iteration of the charter proposal, based on today's 
>> teleconference of the NetSec subcommittee: 
>> https://docs.google.com/document/d/1nrUFymusJV7YrvQBQ-2v6XbJgLGXOIieQMHu6AlaEPc
>>  
>> 
>> Of note, I replaced the previously proposed section 5 with: 
>> " 5. Applicability of new NCSSR versions – Discussion and voting on any 
>> ballot to change the NCSSRs shall proceed within the NetSec WG in accordance 
>> with sections 2.3 and 2.4 of the Bylaws. Additionally, notice of the 
>> proposed ballot and discussion period shall be given to the SCWG, the CSCWG, 
>> and the SMCWG via their Public Mail Lists. If the ballot to change the 
>> NCSSRs passes the Initial Vote, then the new version of the NCSSRs shall be 
>> considered binding and effective on any working group that does not pass a 
>> ballot rejecting the new version before the close of the IPR Review Period." 
>>  
>> On Fri, Nov 5, 2021 at 10:09 AM Tim Hollebeek > > wrote: 
>> So, the approach I’ve been advocating so far in various WGs is the following:
>>  
>> NetSec WG produces and maintains versions of the NCSSRs
>> Individual WGs point to a specific version of the NCSSRs
>> Individual WGs from time to time, evaluate and consume new versions, and 
>> update the version of the NCSSRs they reference
>>  
>> With some iterative feedback and collaboration.  This is the standard way of 
>> handling standards dependencies, and is very much in line with how software 
>> dependencies are handled.  It’s also how, for example, the Code Signing 

Re: [cabfpub] Voting begins on Special Ballot Forum-16: Election of CA/Browser Forum Vice Chair

2020-10-22 Thread Clint Wilson via Public
Apple votes YES on Forum-16.

> On Oct 21, 2020, at 7:15 PM, Dean Coclin via Public  
> wrote:
> 
> Voting begins on this ballot below:



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public


Re: [cabfpub] VOTING BEGINS: Ballot Forum-14 version 2: Creation of S/MIME Certificates Working Group

2020-06-14 Thread Clint Wilson via Public
Apple votes Yes on Forum-14 v2.

> On Jun 8, 2020, at 1:51 PM, Tim Hollebeek via Public  
> wrote:
> 
> The following ballot is proposed by Tim Hollebeek of DigiCert and endorsed by 
> Wayne Thayer of Mozilla and Clint Wilson of Apple.
>  
> Ballot Forum-14: Creation of S/MIME Certificates Working Group
>  
> Purpose of the Ballot
>  
> The CA/Browser Forum underwent a two-year long governance reform exercise, 
> modifying the Bylaws to allow the creation of working groups that covered 
> topics other than server certificates.  While originally motivated by the 
> inability to maintain requirements for code signing certificates, it was 
> anticipated from the start that this would also provide an opportunity to 
> create other working groups that could develop and maintain certificate 
> profiles and requirements for other kinds of certificates.  While a number of 
> regional and technical standards exist regarding the creation and issuance of 
> S/MIME certificates, there is no current global forum for certificate 
> authorities and those who consume or use S/MIME certificates to come together 
> and develop and maintain policies and standards for those certificates.  This 
> lack of standards has impeded the adoption and interoperability of S/MIME 
> certificate worldwide.  This ballot would establish a working group chartered 
> to develop and maintain such standards for S/MIME certificates, including but 
> not limited to two important priorities: a uniform certificate profile for 
> the issuance of publicly-trusted S/MIME certificates, and validation 
> requirements for such certificates.
>  
> -- MOTION BEGINS –
>  
> Establish S/MIME Certificates Working Group
>  
> Upon approval of the CAB Forum by ballot in accordance with section 5.3 of 
> the Bylaws, the S/MIME Certificates Working Group (“SMWG”) is created to 
> perform the activities as specified in the Charter, with the Charter as 
> described here 
> (https://github.com/cabforum/documents/compare/6e0b8e61590164eb2d686ddcf266b189f46fc636...e6ad111f4477010cbff409cd939c5ac1c7c85ccc
>  
> ).
>  
>  
> — MOTION ENDS—
>  
> The procedure for approval of this ballot is as follows:
>  
> Discussion (7+ days)
>  
> Start Time: 2020-06-01 16:40:00 EDT
>  
> End Time: after 2020-06-08 16:40:00 EDT
>  
> Vote for approval (7 days)
>  
> Start Time: 2020-06-08 16:50:00 EDT
>  
> End Time: 2020-06-15 16:50:00 EDT
>  
>  
> ___
> Public mailing list
> Public@cabforum.org 
> https://lists.cabforum.org/mailman/listinfo/public 
> 


smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public


Re: [cabfpub] Creation of S/MIME Certificates Working Group

2020-03-12 Thread Clint Wilson via Public
Thank you Wayne! Similarly, this draft is one Apple would be willing to endorse 
or propose.

Cheers!
-Clint

> On Mar 12, 2020, at 7:43 PM, Wayne Thayer  wrote:
> 
> Thank you Clint! I have reviewed this draft and I'm happy with it. Assuming 
> that Tim and Ryan feel their concerns have been addressed, I am willing to 
> endorse a new ballot on behalf of Mozilla.
> 
> - Wayne
> 
> On Thu, Mar 12, 2020 at 8:07 AM Clint Wilson via Public  <mailto:public@cabforum.org>> wrote:
> Sure thing, here’s a Word formatted version :)
> 
> 
> 
>> On Mar 12, 2020, at 8:05 AM, Ryan Sleevi > <mailto:sle...@google.com>> wrote:
>> 
>> Hey Clint,
>> 
>> Is it possible to convert that file to a standard format? I'm having trouble 
>> opening it 
>> 
>> On Wed, Mar 11, 2020 at 10:30 PM Clint Wilson > <mailto:cli...@apple.com>> wrote:
>> Hello all,
>> 
>> I’ve attached below an updated draft charter which addresses the concerns I 
>> raised previously, especially with regards to section 4.2.3. There are 
>> additionally changes seeking to address Tim and Ryan’s comments/responses 
>> below and a few minor updates that seemed warranted as I went through 
>> another comprehensive review of the document. For each area changed, there 
>> is a corresponding comment; if anything is unclear, please let me know and 
>> I’d be happy to address.
>> 
>> Thank you for your patience and understanding in getting this back to the 
>> group. Have a great evening!
>> -Clint
>> 
>> 
>> 
>>> On Feb 18, 2020, at 1:57 PM, Ryan Sleevi via Public >> <mailto:public@cabforum.org>> wrote:
>>> 
>>> 
>>> 
>>> On Tue, Feb 18, 2020 at 1:57 PM Tim Hollebeek via Public 
>>> mailto:public@cabforum.org>> wrote:
>>> Automatic cessation of membership
>>> The balloted wording around software update cadences introduces some 
>>> precision/definition issues that would likely prove troublesome in and of 
>>> themselves.
>>> While some of those issues could be addressed through wordsmithing, the 
>>> entire precept that membership may be automatically removed based on 
>>> various conditions (both for Certificate Consumers and Issuers) is itself 
>>> problematic and I think an area rife for improvement (both here and in 
>>> other charters).
>>> REJECT: The language is consistent with the language in the other working 
>>> group charters.  Introducing new inconsistencies in this charter would be 
>>> confusing for all involved.  If Apple believes these provisions are 
>>> problematic, potential improvements should be discussed an applied across 
>>> all chartered working groups.
>>> 
>>> 
>>> I'm not quite sure I understand this rationale, could you explain more.
>>> 
>>> Why does this charter need to follow the SCWG/CSWG charter? Who is "all 
>>> involved" that would be confused?
>>> 
>>> It seems very valuable to learn from mistakes and concerns and address 
>>> them, but perhaps I'm overlooking something?
>>>  
>>> Invalid membership requirements/processes
>>> I think Ryan Sleevi has explained most of this better than I could, so I’ll 
>>> refer to his message instead: 
>>> https://cabforum.org/pipermail/public/2020-February/014874.html 
>>> <https://cabforum.org/pipermail/public/2020-February/014874.html>.
>>> I looked, but failed to find information as to how mail transfer agents 
>>> consume S/MIME certificates. However, since it’s included in the ballot I 
>>> can only conclude that the proposer has relevant and detailed insight into 
>>> how and why this is a valid categorization for Certificate Consumers and 
>>> had hoped to be pointed to that information so as to better understand the 
>>> scope of this proposed CWG.
>>> REJECT: This was discussed extensively during the governance reform 
>>> process, and the current procedures were deemed to be sufficient.  This 
>>> charter simply follows those precedents.  Indeed, two other chartered 
>>> working groups were successfully bootstrapped already.
>>> 
>>> 
>>> I understand one group was the Code Signing Working Group, which perhaps 
>>> did not have careful or close review from all Forum members due to the 
>>> explicit lack of intent to participate in the venue or fundamental 
>>> disagreements about the working group objectives.
>>> 
>>> However, I'm not sure, what's the other Chartered Wo

Re: [cabfpub] Creation of S/MIME Certificates Working Group

2020-03-12 Thread Clint Wilson via Public
Sure thing, here’s a Word formatted version :)

SMIME Charter 2020-03-02_ctw.docx
Description: MS-Word 2007 document
On Mar 12, 2020, at 8:05 AM, Ryan Sleevi  wrote:Hey Clint,Is it possible to convert that file to a standard format? I'm having trouble opening it On Wed, Mar 11, 2020 at 10:30 PM Clint Wilson  wrote:Hello all,I’ve attached below an updated draft charter which addresses the concerns I raised previously, especially with regards to section 4.2.3. There are additionally changes seeking to address Tim and Ryan’s comments/responses below and a few minor updates that seemed warranted as I went through another comprehensive review of the document. For each area changed, there is a corresponding comment; if anything is unclear, please let me know and I’d be happy to address.Thank you for your patience and understanding in getting this back to the group. Have a great evening!-ClintOn Feb 18, 2020, at 1:57 PM, Ryan Sleevi via Public  wrote:On Tue, Feb 18, 2020 at 1:57 PM Tim Hollebeek via Public  wrote:Automatic cessation of membershipThe balloted wording around software update cadences introduces some precision/definition issues that would likely prove troublesome in and of themselves.While some of those issues could be addressed through wordsmithing, the entire precept that membership may be automatically removed based on various conditions (both for Certificate Consumers and Issuers) is itself problematic and I think an area rife for improvement (both here and in other charters).REJECT: The language is consistent with the language in the other working group charters.  Introducing new inconsistencies in this charter would be confusing for all involved.  If Apple believes these provisions are problematic, potential improvements should be discussed an applied across all chartered working groups.I'm not quite sure I understand this rationale, could you explain more.Why does this charter need to follow the SCWG/CSWG charter? Who is "all involved" that would be confused?It seems very valuable to learn from mistakes and concerns and address them, but perhaps I'm overlooking something? Invalid membership requirements/processesI think Ryan Sleevi has explained most of this better than I could, so I’ll refer to his message instead: https://cabforum.org/pipermail/public/2020-February/014874.html.I looked, but failed to find information as to how mail transfer agents consume S/MIME certificates. However, since it’s included in the ballot I can only conclude that the proposer has relevant and detailed insight into how and why this is a valid categorization for Certificate Consumers and had hoped to be pointed to that information so as to better understand the scope of this proposed CWG.REJECT: This was discussed extensively during the governance reform process, and the current procedures were deemed to be sufficient.  This charter simply follows those precedents.  Indeed, two other chartered working groups were successfully bootstrapped already.I understand one group was the Code Signing Working Group, which perhaps did not have careful or close review from all Forum members due to the explicit lack of intent to participate in the venue or fundamental disagreements about the working group objectives.However, I'm not sure, what's the other Chartered Working Group you're thinking of? The SCWG explicitly did not follow this process, as part of the Legacy Working Group transition, and so I'm not sure what the other CWG is that avoided this?Also, while I agree that this was discussed extensively, I must respectfully disagree that the "current procedures were deemed to be sufficient". The current (proposed) procedures were known to be problematic in bootstrapping, something we discussed, and something we knew we could avoid by defining an open and welcoming charter. This WG does not seem to set out to do this.In all fairness, this seems a repeat of the same issues the bedeviled, and nearly derailed, the Forum in it's first start. The attempt to exclude some CAs, via narrowly and restrictively scoped membership, nearly resulted in the implosion of the Forum, as the management@ archives from 2009 show. Ultimately, it was the Forum's rejection of such exclusionary attempts that helped grow the membership. In particular, it was DigiCert who some were trying to prevent from joining the Forum, so it would be unfortunate to have DigiCert repeat that same process.I'm hoping you're open to addressing these issues, but I don't think we can support the charter without this issue being addressed.
___Public mailing listPublic@cabforum.orghttps://cabforum.org/mailman/listinfo/public


smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public


Re: [cabfpub] Voting Begins: Forum-11: Creation of S/MIME Certificates Working Group

2020-02-07 Thread Clint Wilson via Public
Apple votes “No” on Forum-11.

Aside from - or perhaps above all - the concerns outlined below and addressed 
in the edited draft I shared with the list here 
(https://cabforum.org/pipermail/public/2020-January/014859.html 
), Apple votes 
“No” partially on principle of there being minimal attempt to engage in 
respectful discourse around feedback provided ~during the discussion period, 
evidenced by leaving no time to respond prior to forcing the ballot to vote. I 
simply don’t believe that all of the substantive feedback below are 
“fundamentally incompatible with the path forward we agreed to in Guangzhou”; I 
question whether discussing new points under time pressure of a voting period 
is the most productive way to ensure those points are adequately addressed.

There are a number of concerns with the version of the charter associated to 
this ballot. I regret, truly, that these issues weren’t all raised, nor 
addressed, prior to the voting period beginning, as I strongly support the 
basic intent of this ballot and hopefully future CWG. We, as an industry, need 
a consistent, auditable set of requirements against which S/MIME certificates 
can be issued and, when compliant, reliably and intercompatibly consumed by 
software providers. Email as a tool for the betterment of humankind has proven 
so effective as to be arguably invaluable; improving the security, privacy, and 
safety of using email is a very worthwhile goal which we unequivocally share 
with the ballot proposer and endorsers. Similarly, I do empathize with the 
impatience which is inevitably felt by those who have shepherded this document 
along these past years and would like to thank Dimitris for his helpful 
comments regarding the proposed changes, which I hope are addressed below.

Moving fast and breaking things is a mantra I can support in some low-risk, 
low-impact situations. The formation of such a pivotal working group is not one 
of them. Highlighted below are some high-level groupings of the concerns we 
have and to which we shared an updated draft proposal that addresses these same 
concerns.
Factual/technical inaccuracies
A private key associated with an S/MIME certificate is not used to encrypt 
emails; the public key is.
An S/MIME certificate as defined solely through the presence of the 
emailProtection EKU does not, necessarily, have the capability of signing email 
(which is typically determined by a keyUsage OID).
Grammatical corrections
“ voting membership in the SMCWG must produce a develop and maintain” 
is clearly simply a grammatical error. 
The numbering of charter sections is incorrect after #4.
Overemphasis on identity
This is understandably subjective, but I’m not sure the edits I proposed 
conveyed fully the concern. 
We have no objection to CAs including identity information in S/MIME 
certificates generally speaking, and believe the SMCWG to be the appropriate 
venue for establishing S/MIME certificate profiles including subject identity 
information. You can see subject identity information in the S/MIME certificate 
used to sign this email, just to provide a little good-faith evidence backing 
this statement (though it shouldn’t be necessary...).
What we do strongly object to is the potential for the working group to be 
sidelined into re-creation and bifurcation of identity validation processes. I 
don’t know the best way to express this in the charter (though I submitted my 
attempt) and that’s part of what I hoped discussion prior to voting to include, 
but I suppose this is an item where I’m simply “late to the party”.
Imprecise pronoun usage
“validate an email address and the subject’s identity prior to binding it to 
the email address” indicates the email address is bound to the email address? 
Or the subject’s identity is bound to the email address? 
I would posit this could instead be better categorized as a factual inaccuracy, 
assuming the intent was to convey the binding of (email address) || (email 
address && subject identity) to a public key in a certificate.
Inconsistent incorporation of pre-existing and suitable reference work
In the closing paragraph of the Introduction section, it’s unclear why it’s 
appropriate to acknowledge existing methods for validating control of a domain, 
but not (in the same paragraph and context) acceptable to acknowledge existing 
methods for validating the identity of a subject. The conclusion this 
inconsistency points to for me is that the BRs and EVGs are insufficient to 
fully validate the identity of a subject. I believe this to be an erroneous 
conclusion, which I attempted to correct for with my proposed changes. 
If I’ve misunderstood and it is instead the position of the proposer that these 
other working group artifacts are indeed insufficient in representing 
“consistent and audited validation practices used by CAs in establishing the 
identity of a subject”, I think that 

Re: [cabfpub] Ballot Forum-11: Creation of S/MIME Certificates Working Group

2020-01-31 Thread Clint Wilson via Public
Hi all,I apologize for not getting this feedback in prior to the end of the Discussion period. I’ve attached a redlined document with comments and proposed changes (though I didn’t update the format to follow the template in the Bylaws). I hope this feedback can still be considered prior to the ballot being submitted for a vote.Thank you!-Clint

Draft SMIME Charter 2020-01-31-ctw.docx
Description: MS-Word 2007 document
On Jan 24, 2020, at 11:39 AM, Tim Hollebeek via Public  wrote: The following ballot is proposed by Tim Hollebeek of DigiCert and endorsed by Wayne Thayer of Mozilla and Adriano Santoni of Actalis. Ballot Forum-11: Creation of S/MIME Certificates Working Group Purpose of the Ballot The CA/Browser Forum recently underwent a two-year long governance reform exercise, modifying the Bylaws to allow the creation of working groups that covered topics other than server certificates.  While originally motivated by the inability to maintain requirements for code signing certificates, it was anticipated from the start that this would also provide an opportunity to create other working groups that could develop and maintain certificate profiles and requirements for other kinds of certificates.  While a number of regional and technical standards exist regarding the creation and issuance of S/MIME certificates, there is no current global forum for certificate authorities and those who consume or use S/MIME certificates to come together and develop and maintain policies and standards for those certificates.  This lack of standards has impeded the adoption and interoperability of S/MIME certificate worldwide.  This ballot would establish a working group chartered to develop and maintain such standards for S/MIME certificates, including but not limited to two important priorities: a uniform certificate profile for the issuance of publicly-trusted S/MIME certificates, and validation requirements for such certificates. -- MOTION BEGINS – Establish S/MIME Certificates Working Group Upon approval of the CAB Forum by ballot in accordance with section 5.3 of the Bylaws, the S/MIME Certificates Working Group (“SMWG”) is created to perform the activities as specified in the attached Charter. — MOTION ENDS— The procedure for approval of this ballot is as follows: Discussion (7+ days) Start Time: 2020-01-24  14:40:00 EDT End Time: after 2020-01-31 14:40:00 EDT Vote for approval (7 days) Start Time: TBD End Time: TBD___Public mailing listPublic@cabforum.orghttps://cabforum.org/mailman/listinfo/public

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public