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

[Ben Wilson via Public]

Mozilla votes "Yes" on Forum-022, and I'll assume that is what was meant by
Antti.

On Thu, May 16, 2024 at 2:55 AM Backman, Antti <
antti.back...@teliacompany.com> wrote:

> Telia votes ’Yes’ on Ballot FORUM-002
>
>
>
> //Antti
>
>
>
> *From: *Public  on behalf of Ben Wilson via
> Public 
> *Date: *Wednesday, 15. May 2024 at 18.02
> *To: *CA/Browser Forum Public Discussion List 
> *Subject: *[cabfpub] Voting Period Begins: Ballot FORUM-022: Establish
> Forum IPR Subcommittee
>
> *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

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

[Ben Wilson via Public]

*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

[cabfpub] Bergamo F2F Agenda Item

[Ben Wilson via Public]

Hi Dimitris,
There appears to be an open slot on the F2F agenda - Wed. May 29th at 9:05
a.m.  I was thinking we could use that time to discuss revocation timelines
and balancing the security provided by revocation with the
security/stability needed to support critical infrastructure. In other
words, we could discuss BR section 4.9.1 and  concerns about disruption of
global/national operations in banking/finance, transportation, government,
telecommunications, healthcare, and other key areas where certificate
revocation might cause key systems to fail.
Should I put this topic in that open slot on the wiki?
Thanks,
Ben
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

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

[Ben Wilson via Public]

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

End Time: TBD
___
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

[Ben Wilson via Public]

Mozilla wants to participate in the new Definitions and Glossary Working
Group.

On Mon, Apr 22, 2024 at 10: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
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] Draft Charter for IPR Subcommittee

[Ben Wilson via Public]

All,

Here is a revised Charter for the Forum IPR Subcommittee ("FIPR").

https://github.com/BenWilson-Mozilla/forum/blob/fipr-charter/FIPR-Charter.md

Thanks,

Ben

On Fri, Apr 19, 2024 at 11:59 AM Dimitris Zacharopoulos (HARICA) via Public
 wrote:

> Hi  Ben,
>
> On 16/4/2024 7:48 μ.μ., Ben Wilson via Public 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.
>
>
> I'm not sure the IPR Policy needs to be invoked here. Please take a look
> at the Forum Infrastructure SC charter (
> https://cabforum.org/2019/10/08/ballot-forum-10-re-charter-forum-infrastructure-working-group/).
> Also, is it ok to use the acronym "FIS" as it is also referred in the Forum
> Subcommittee 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.
>
>
> Based on the last statement, I don't think we need to mention that this
> charter is subject to the IPR Policy.
>
> *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.
>
>
> If the Subcommittee completes its deliverables and those deliverables are
> accepted by the Forum by ballot, the subcommittee should probably be
> dissolved automatically. We could renew its charter or duration if we find
> something else useful but based on the current expectations it looks like
> it will be dissolved if the proposed documents are approved.
>
> *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.
>
>
> This is not a WG so no voting or voting structure is necessary.
>
> *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.
>
>
> I suggest we combine some elements from
> https://cabforum.org/2019/10/08/ballot-forum-10-re-charter-forum-infrastructure-working-group/
> to improve this charter.
>
> Thanks Ben for putting this together!
>
> Dimitris.
>
>
>
> ___
> Public mailing 
> listPublic@cabforum.orghttps://lists.cabforum.org/mailman/listinfo/public
>
>
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] Draft Charter for IPR Subcommittee

[Ben Wilson via Public]

Thanks, Dimitris.

I will make edits to the proposal and get back to everyone.

Ben

On Fri, Apr 19, 2024 at 11:59 AM Dimitris Zacharopoulos (HARICA) via Public
 wrote:

> Hi  Ben,
>
> On 16/4/2024 7:48 μ.μ., Ben Wilson via Public 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.
>
>
> I'm not sure the IPR Policy needs to be invoked here. Please take a look
> at the Forum Infrastructure SC charter (
> https://cabforum.org/2019/10/08/ballot-forum-10-re-charter-forum-infrastructure-working-group/).
> Also, is it ok to use the acronym "FIS" as it is also referred in the Forum
> Subcommittee 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.
>
>
> Based on the last statement, I don't think we need to mention that this
> charter is subject to the IPR Policy.
>
> *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.
>
>
> If the Subcommittee completes its deliverables and those deliverables are
> accepted by the Forum by ballot, the subcommittee should probably be
> dissolved automatically. We could renew its charter or duration if we find
> something else useful but based on the current expectations it looks like
> it will be dissolved if the proposed documents are approved.
>
> *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.
>
>
> This is not a WG so no voting or voting structure is necessary.
>
> *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.
>
>
> I suggest we combine some elements from
> https://cabforum.org/2019/10/08/ballot-forum-10-re-charter-forum-infrastructure-working-group/
> to improve this charter.
>
> Thanks Ben for putting this together!
>
> Dimitris.
>
>
>
> ___
> Public mailing 
> listPublic@cabforum.orghttps://lists.cabforum.org/mailman/listinfo/public
>
>
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] Draft Charter for IPR Subcommittee

[Ben Wilson via Public]

Hi Martijn,

I was thinking that there may be miscellaneous decisions where the
Subcommittee might need to vote. There is no intent that the Subcommittee
would be able to "adopt" a new IPR Policy, if that is your concern.

I was proposing that only Forum Members would be eligible to participate on
the Subcommittee, so Associate Members, Probationary Members and Interested
Parties would not be participating on the Subcommittee, nor would they have
a vote.

Thanks,

Ben

On Fri, Apr 19, 2024 at 1:55 AM Martijn Katerbarg <
martijn.katerb...@sectigo.com> wrote:

> Ben, a few questions / clarifications:
>
>
>
> > Voting in the FIS shall be limited to Forum members. Voting shall be
> egalitarian: all Members shall vote together as a single
>
> Does this mean the Subcommittee will run a ballot rather than the Forum,
> or will the Forum still run the actuall ballot?
>
>
>
> > Voting shall be egalitarian: all Members shall vote together as a
> single class
>
> Is the intent here to also allow Associated Members, Probationary Members
> and Interested Parties to vote?
>
> Regards,
>
> Martijn
>
>
>
> *From: *Public  on behalf of Ben Wilson via
> Public 
> *Date: *Thursday, 18 April 2024 at 17:37
> *To: *CA/Browser Forum Public Discussion List 
> *Subject: *Re: [cabfpub] Draft Charter for IPR Subcommittee
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> All,
>
> 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

Re: [cabfpub] Draft Charter for IPR Subcommittee

[Ben Wilson via Public]

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

[cabfpub] Draft Charter for IPR Subcommittee

[Ben Wilson via Public]

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

Re: [cabfpub] Patent Advisory Group Formation

[Ben Wilson via Public]

Just a reminder -
If you or your IP counsel are interested in participating in the Patent
Advisory Group, please let me know by close of business Friday.
Thanks.  Ben

On Thu, Mar 28, 2024 at 11:03 AM Ben Wilson via Public 
wrote:

> All,
> In today's Forum call, I announced that we are collecting the names and
> email addresses of participants in the Patent Advisory Group through
> Friday, April 12, 2024, and then we'll get started.
> Thanks,
> Ben
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
___
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

[Ben Wilson via Public]

Mozilla votes "yes" on Ballot FORUM-021.

Thanks.

On Thu, Apr 4, 2024 at 9: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
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

[cabfpub] Patent Advisory Group Formation

[Ben Wilson via Public]

All,
In today's Forum call, I announced that we are collecting the names and
email addresses of participants in the Patent Advisory Group through
Friday, April 12, 2024, and then we'll get started.
Thanks,
Ben
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

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

[Ben Wilson via Public]

Looks good to me.
Ben

On Thu, Mar 21, 2024 at 9:00 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*: After 2024-Mar-28 15:00 UTC
>
> *Vote for approval* (7 days)
>
> Start Time: TBD
> End Time: TBD
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] Voting Period begins: Ballot FORUM-020 v2 - Amend Code Signing Certificate Working Group Charter

[Ben Wilson via Public]

Mozilla votes "Yes" on Ballot FORUM-020 v.2.

On Thu, Jan 4, 2024 at 1:02 PM Martijn Katerbarg via Public <
public@cabforum.org> wrote:

> *Ballot FORUM-020 **v2 - Amend Code Signing Certificate Working Group
> Charter*
>
>
>
> *Purpose of Ballot*
>
> This ballot proposes to amend the Code Signing Certificate Working Group
> (CSCWG) Charter with the following changes:
>
>- Bump the Charter version.
>- Add a limited scope for timestamp certificates.
>- Remove the version reference of the bylaws that we follow.
>- During a ballot, count only members that are in a voting class,
>disregarding associate members and interested parties.
>- Align Quorum definition as half the average, as the Bylaws have it
>set.
>
>
>
> The following motion has been proposed by Martijn Katerbarg of Sectigo and
> endorsed by Bruce Morton of Entrust and Dimitris Zacharopoulos of HARICA.
>
>
>
> - Motion Begins -
>
>
>
> MODIFY the Charter of the Code Signing Certificate Working Group as
> specified in the following redline:
>
> https://github.com/cabforum/forum/compare/59185f16917cc7f5b83564fe5fddff32cf84c8ce...b80c98b80ee132e2a3adf09bfa8ba7448084d11d
> 
>
>
>
> - 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-12-14 – 16:00 UTC
>
> End Time: 2024-01-04 – 20:00 UTC
>
>
>
> Vote for approval (7 days)
>
> Start Time: 2024-01-04 – 20:00 UTC
>
> End Time:  2024-01-11 – 20:00 UTC
>
>
>
>
>
>
>
>
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
___
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

[Ben Wilson via Public]

Mozilla votes "yes" on Ballot FORUM-019 v.2.

On Mon, Nov 27, 2023 at 8: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
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

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

[Ben Wilson via Public]

 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

Re: [cabfpub] Ballot FORUM-019 - Amend Server Certificate Working Group Charter - Discussion Period

[Ben Wilson via Public]

Thanks, Tobias.
I'll take a look at your suggestions and see if I can work in a few
revisions, and then we can restart the discussion period.
Ben

On Thu, Oct 26, 2023 at 12:30 PM Tobias S. Josefowitz 
wrote:

> Hi Ben,
>
> On Mon, 23 Oct 2023, Ben Wilson wrote:
>
> > *Ballot FORUM-019:  Amend Server Certificate Working Group Charter*
> >
> > *Purpose of the Ballot*
> >
> > This ballot proposes changes to 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, 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.
> >
> > *Motion Begins*
> >
> > MODIFY the Charter of the Server Certificate Working Group as specified
> in
> > the following redline:
> >
> >
> https://github.com/cabforum/forum/compare/59185f16917cc7f5b83564fe5fddff32cf84c8ce?f029c48cfd8a53ca563904835d6bd5d4b41fa4c8
> >
> > *Motion Ends*
>
> My biggest concern with this Ballot is the language in 4. (d), which
> introduces the limitation of "upon the request of any Member that
> challenges the Applicant's adherence to all of the requirements of section
> 3(a) or 3(b)" for requesting the membership to be decided by a vote.
>
> I recognize that we have members that interpret the current mechanism of
> deciding membership by vote "upon the request of any Member" to only
> result in a vote about the applicant meeting the formal membership
> criteria. Understandably, from that perspective, adding pretty much any
> sensible requirement to the list of formal membership criteria for
> Certificate Consumer members is obviously beneficial and without any
> downsides.
>
> As someone who does not share that perspective but maintains that the
> current "upon the request of any Member" mechanism results in a vote in
> which members can apply a level of discretion which allows at least e.g.
> refusing membership to applicants who's membership (if granted) might
> substantially erode trust into the WebPKI ecosystem or endanger the SCWG's
> ability to maintain and produce documents that are incorporated into root
> program policies in a mostly verbatim fashion, the new language is
> extremely concerning.
>
> When taking into account that the new set of requirements for Certificate
> Consumers can indeed still be trivially met by even a single individual
> with a few hours of time on their hands (unless, maybe, "software product
> intended for use by the general public for browsing the Web securely"
> somehow will turn into a requirement that will not be considered to be
> trivially fulfilled), the new language in my opinion becomes
> disqualifying. I hope that this change to the mechanism can be reverted
> until we have a set of formal membership criteria for Certificate
> Consumers that makes such discretion obsolete.
>
> In addition, I have some minor concerns regarding the new formal
> membership criteria for Certificate Consumers in 3.(b). In particular, for
> the sake of the argument, I assume a browser that generally uses the OS
> root store as a base mechanism (potentially with the ability to exclude
> specific certificates that might be included in the OS root store). It is
> my understanding that for example Google Chrome has worked like this until
> somewhat recently, which to me kind of implies that it ought to be
> considered an acceptable practice for SCWG Certificate Consumer Member
> qualifying software products in good standing. From our discussion during
> the F2F #60 (I am not sure if this was in the SCWG or Forum plenary) I
> understand that you intend
>
>"its membership-qualifying software product uses a list of CA
>certificates to validate the chain of trust from a TLS certificate to a
>CA certificate in such list"
>
> to cover that case. However, such a software as described would indeed use
> different lists on different platforms. We could consider the specific
> version for one platform to be the "membership qualifying software", but
> that does not seem elegant, and might come into conflict with "for the
> general public" in a strict interpretation.
>
> In such a case, it would also be problematic to
>
>"publishes the list of CA certificates used to validate the chain of
>trust from a TLS certificate to a CA certificate in such list"
>
> as any static copy of such a list would only give an indication of intent,
> but misses to represent the actual mechanism at play. It would in this
> case be much more reasonable to simply explain how the mmebership
> qualifying software decides which certificates to trust.
>
> In 

Re: [cabfpub] Forum Ballot to Amend Server Certificate WG Charter

[Ben Wilson via Public]

Thanks for your input, Dimitris.
I've amended section 4.d. as proposed -
https://github.com/cabforum/forum/commit/c6850e24eb49d5cfcb00eae4d11e82544504bffb
Thanks again,
Ben

On Wed, Oct 18, 2023 at 3:03 AM Dimitris Zacharopoulos (HARICA) <
dzach...@harica.gr> wrote:

>
> Hello Ben,
>
> At F2F58
> <https://cabforum.org/2023/03/02/minutes-of-the-f2f-58-meeting-in-ottawa-canada-28-february-1-march-2023/>we
> had a discussion about the lessons learned from ballot SC60
> <https://cabforum.org/wp-content/uploads/11-CABF_Lessons-learned-from-SC60.pdf>.
> During that meeting, a proposal was made that seems to fix the ambiguity of
> the current Bylaws.
>
> In line 93 of the proposed ballot, it says:
>
> ***(d)** There is a mandatory six-month probationary period during which
> any representative of an Applicant must attend at least 30% of all SCWG
> teleconferences (not counting subcommittee meetings) and at least one SCWG
> face-to-face meeting (either physically or virtually). After successful
> completion of the mandatory probationary period and meeting all
> requirements of section 3(a) or 3(b), an Applicant may become a Voting
> Member, if the SCWG determines by consensus among the Members during a
> Meeting or Teleconference, or upon the request of any Member, by a Ballot
> among the Members, that the Applicant meets the requirements of section
> 3(a) or 3(b). Acceptance by consensus shall be determined, or a Ballot of
> the Members shall be held, as soon as the Applicant indicates that it has
> presented all information required and has responded to all follow-up
> questions from the SCWG and the Applicant has complied with the
> requirements of Section 5.5 of the CA/Browser Forum Bylaws.*
>
>
> Instead of:
>
> *"or upon the request of any Member, by a Ballot among the Members, by a
> Ballot among the Members, that the Applicant meets the requirements of
> section 3(a) or 3(b)" *
>
> please update to:
>
> *"or upon the request of any Member that challenges the Applicant's
> adherence to all of the requirements of section 3(a) or 3(b), by a Ballot
> among the Members."*
>
> I read the rest of the proposed changes and they look good. If you are ok
> with the change above, HARICA would be happy to endorse the ballot.
>
>
> Best regards,
> Dimitris.
>
> On 13/10/2023 1:23 π.μ., Ben Wilson via Public wrote:
>
> All,
>
> I am planning to introduce a Forum ballot to amend the Server Certificate
> Working Group Charter.
>
> At a high level, here are some of the proposed changes:
>
>- Section numbering added
>- "Root Certificate Issuer" voting category removed
>- Membership requirements for Certificate Consumers added
>- 6-month probationary period prior to voting membership added
>- Voting percentages and quorum clarified
>
> Because there are numerous proposed changes, here are a diff and a blob
> for your review.
>
> <http://goog_919727606>
>
> https://github.com/cabforum/forum/compare/59185f16917cc7f5b83564fe5fddff32cf84c8ce...85e569a43a5a2c9e5e16ce8bf1e569a98cfbd720
>
> <https://mail.google.com/mail/u/0/goog_919727603>
>
> https://github.com/cabforum/forum/blob/BenWilson-SCWG-charter-1.3/SCWG-charter.md
>
> I look forward to your comments and suggestions.
>
> Thanks,
>
> Ben
>
>
> ___
> Public mailing 
> listPublic@cabforum.orghttps://lists.cabforum.org/mailman/listinfo/public
>
>
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] Forum Ballot to Amend Server Certificate WG Charter

[Ben Wilson via Public]

All,

I am looking for at least one more endorser for this ballot.

Thanks,

Ben

On Thu, Oct 12, 2023 at 4:23 PM Ben Wilson  wrote:

> All,
>
> I am planning to introduce a Forum ballot to amend the Server Certificate
> Working Group Charter.
>
> At a high level, here are some of the proposed changes:
>
>- Section numbering added
>- "Root Certificate Issuer" voting category removed
>- Membership requirements for Certificate Consumers added
>- 6-month probationary period prior to voting membership added
>- Voting percentages and quorum clarified
>
> Because there are numerous proposed changes, here are a diff and a blob
> for your review.
>
> 
>
> https://github.com/cabforum/forum/compare/59185f16917cc7f5b83564fe5fddff32cf84c8ce...85e569a43a5a2c9e5e16ce8bf1e569a98cfbd720
>
> 
>
> https://github.com/cabforum/forum/blob/BenWilson-SCWG-charter-1.3/SCWG-charter.md
>
> I look forward to your comments and suggestions.
>
> Thanks,
>
> Ben
>
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

[cabfpub] Forum Ballot to Amend Server Certificate WG Charter

[Ben Wilson via Public]

All,

I am planning to introduce a Forum ballot to amend the Server Certificate
Working Group Charter.

At a high level, here are some of the proposed changes:

   - Section numbering added
   - "Root Certificate Issuer" voting category removed
   - Membership requirements for Certificate Consumers added
   - 6-month probationary period prior to voting membership added
   - Voting percentages and quorum clarified

Because there are numerous proposed changes, here are a diff and a blob for
your review.


https://github.com/cabforum/forum/compare/59185f16917cc7f5b83564fe5fddff32cf84c8ce...85e569a43a5a2c9e5e16ce8bf1e569a98cfbd720


https://github.com/cabforum/forum/blob/BenWilson-SCWG-charter-1.3/SCWG-charter.md

I look forward to your comments and suggestions.

Thanks,

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

[Ben Wilson via Public]

Mozilla votes "Yes" on Ballot Forum-018 v3

On Thu, Jul 13, 2023 at 2:43 AM Dimitris Zacharopoulos (HARICA) via Public <
public@cabforum.org> 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:
>
>1. Clarified that it is not always required to “READ” the antitrust
>statement before each meeting and added the option of reading a 
> "note-well".
>2. Clarified where to send/post Chartered Working Group minutes.
>3. Increased the number of days before automatic failing a ballot from
>21 to 90 days.
>4. Allow Chair or Vice-Chair to update links to other sections within
>a document without a ballot.
>5. Applied grammatical and other language improvements.
>6. Clarified that Subcommittee minutes do not need to also be
>published on the public web site.
>7. 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.
>8. Clarified language for Associate Members for consistency with
>Probationary Member for the ballot proposals and endorsing.
>9. Removed the member category called "Root CA Issuer" and only kept
>the "CA Issuer" category.
>10. Added a step to check the authority of the signer during
>membership applications.
>11. Updated the Chartered Working Group template.
>12. Added some language to the Code of Conduct.
>13. Publishing private conversations without express permission is
>considered a violation of the Code of Conduct.
>14. 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
>
>1. Bylaws-redline.pdf (attached)
>2. 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
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

[cabfpub] Ballot FORUM-0XX: Modify Charter of Server Certificate Working Group

[Ben Wilson via Public]

Here is a draft ballot to modify the Charter of the Server Certificate
Working Group.

*Ballot FORUM-0XX:  Modify Charter of Server Certificate Working Group*

*Purpose of the Ballot*

During discussions at Face-to-Face Meeting 58, it was noted that the
membership criteria for Certificate Consumers in the Charter for the Server
Certificate Working Group (SCWG) lacked sufficient detail. Since then,
several members of the CA/Browser Forum have worked to develop better
criteria for membership of Certificate Consumers in the SCWG.

This ballot modifies the Charter of the SCWG based on version 1.2 and
changes the criteria for voting membership of both Certificate Issuers and
Certificate Consumers in the SCWG.

The following motion has been proposed by Ben Wilson of Mozilla and
endorsed by __ of __ and _ of _.

*Motion Begins*

MODIFY the Charter of the Server Certificate Working Group as specified in
the following redline:

https://github.com/cabforum/forum/compare/d908a475e59e64fd9224e878864386ebc0b68808..9bef376326869b1bc83fcdcb04ed66343393104a

*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 (7 days)

Start Time: 2023-05-XX  xx:xx UTC

End Time: Not before 2023-05-xx  xx:xx UTC



Vote for approval (7 days)

Start Time: TBD

End Time: TBD


I am looking for two endorsers.


Thanks,


Ben
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] Final Minutes for CA/Browser Forum Teleconference - January 5, 2023

[Ben Wilson via Public]

Do you want me to post these to the website?

On Tue, Jan 24, 2023 at 12:08 AM Dimitris Zacharopoulos (HARICA) via Public
 wrote:

> These are the approved Minutes of the Teleconference described in the
> subject of this message, prepared by Andrea Holland (VikingCloud).
>
> *Forum Meeting: January 5, 2023*
>
> *Attendance (in alphabetical order):*
>
> Aaron Gable (ISRG), Aaron Poulsen (Amazon Trust Services), Adam Jones
> (Microsoft), Andrea Holland (VikingCloud), Atsushi Inaba (GlobalSign), Ben
> Wilson (Mozilla), Bruce Morton (Entrust), Chris Clements (Google Chrome),
> Chris Kemmerer (SSL.com), Clint Wilson (Apple), Corey Bonnell (DigiCert),
> Corey Rasmussen (OATI), Daryn Wright (GoDaddy), Dean Coclin (DigiCert),
> Dimitris Zacharopoulos (HARICA), Dustin Hollenback (Microsoft),  Ellie
> (TrustAsia), Enrico Entschew (D-TRUST), Eva Van Steenberge (GlobalSign),
> Fumi Yoneda (JPRS), Hazhar Ismail (MSC Trustgate), Inigo Barreira
> (Sectigo), Jamie Mackey (FPKI), Janet Hines (VikingCloud), Joanna Fox
> (TrustCor), Jos Purvis (Fastly), Karina Sirota Goodley (Microsoft), Kiran
> Tummala (Microsoft), Lynn Jeun (Visa), Mads Henriksveen (Buypass), Marcelo
> Silva (Visa), Marco Schambach (IdenTrust), Michelle Coon (OATI), Mrugesh
> Chandarana (IdenTrust), Nargis Mannan (VikingCloud), Peter Miskovic
> (Disig), Rich Smith (DigiCert), Rollin Yu (Trust Asia), Sissel Hoel
> (Buypass), Stephen Davidson (DigiCert), Steve Topletz (Cisco), Tadahiko Ito
> (SECOM), Tim Hollebeek (DigCert), Tobias Josefowitz (Opera), Trevoli
> Ponds-White (Amazon Trust Services), Wayne Thayer (Fastkt), Wendy Brown
> (FPKI), Yoshiro Yoneya (JPRS)
>
>
>
> *Minutes*
>
>1. *Roll called*
>2. *Antitrust statement read*
>3. *Reviewed Agenda*
>4. *Approval of minutes*: December 29th meeting minutes approved
>5. *Forum Infrastructure Subcommittee* – Jos P.
>
>
>- Did not meet last week, no significant updates
>- Working on migration to new wiki which involves archiving the
>existing wiki and pulling items from there into the new wiki
>- Will be posting details and invitations to the management list
>
>
>1. *Code Signing Certificate Working Group* – Dean C. and Bruce M.
>
>
>- Did not meet last week, no significant updates
>- Continuing to work on ballot for cert revocation due to malware,
>signing service requirements and removing TLS BR references from CS BRs
>
>
>1. *S/MIME Certificate Working Group* – Dean C., Corey B., Inigo B.,
>Dimitris Z.
>
>
>- IPR period finished for the new BRs
>- Discussion on auditors developing audit criteria for the new
>requirements. WebTrust is aware and will do further discussions during
>their Toronto meeting
>- CAA discussion in IETF’s LAMPs WG, general support for adopting
>draft proposal for CAA for SMIME
>- Stephen also had some ERATA for future updates, he is generating
>GitHub issues for these minor issues
>
>
>1. *NetSec Working Group* – Clint W.
>
>
>- Did not meet last week
>- Continued discussion around the separation of concepts of offline vs
>air gapped vs unpowered HSMs and key materials to make sure the BRs clearly
>address the differences
>- Organization of NSRs to provide better introduction of NSRs without
>changing the goals but language to describe the intent of the various
>sections and components
>- Trev P.: Issues with the meeting it looked to be cancelled
>   - Clint W.: Wiki has latest calendar invite for the meeting
>   - Dimitris Z.: Same issue with forum calendar invite. An alias was
>   created, so that whenever there is a change in chair positions only the
>   password needs to be reset. This allows for management of the 
> invitations
>   without needing to create a new series of meetings. This would be a good
>   idea for other meetings as well. But for WebEx best way to cancel the
>   meetings is through the UI so all registrants get the notice.
>- GitHub Approvals
>   - Dimitris Z.: Each WG has its own repository with review and
>   approval from Chair and Vice Chair
>   - Jos P.: A Code owner’s file exists in each of the repositories
>   for each of the working groups.  To publish anything to the main branch 
> of
>   that repository (to formally update the BRs) requires two people to 
> approve
>   and one must be on the code owners list. So if someone wants to make a
>   change, they go through the balloting process and then the chair 
> approves
>   the update and it requires another person for approval for sanity 
> purposes
>   to add to the main branch. At the moment only the Chair and Vice Chair 
> can
>   approve, so if either of them is out (especially for a long period) 
> then we
>   cannot get approval. If for instance, the Chair does the pull request, 
> then
>   the Chair cannot approve those changes and there is only one person, the
>   Vice Chair, able to 

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

[Ben Wilson via Public]

Mozilla votes "Yes" on Ballot Forum-18.

On Wed, Jul 27, 2022 at 1:10 PM Tim Hollebeek via Public <
public@cabforum.org> wrote:

>
>
> Ballot FORUM-18, Allow Re-election of CWG Chairs and Vice Chairs
>
>
>
> Proposed by Tim Hollebeek of DigiCert and endorsed by Ben Wilson of
> Mozilla and Wayne Thayer of Fastly.
>
>
>
> Overview
>
>
>
> Section 4.1 of the Bylaws describes elections for Forum Chair and Vice
> Chair, and says:
>
>
>
> "No person may serve as Chair for more than a two-year period or be
> elected to Vice Chair upon expiration or termination
>
> of the person’s service as Chair, but a person is eligible to be elected
> as Chair again after having vacated the position
>
> as Chair for at least one (1) term."
>
>
>
> This makes it clear Forum Chairs and Vice Chairs cannot be re-elected (be
> elected to a new term for the same office they
>
> currently hold), but the situation is less clear for Chairs and Vice
> Chairs of Chartered Working Groups (CWGs).
>
>
>
> The current Bylaws have been read by some to allow re-election of CWG
> Chairs and Vice Chairs, and by others to prohibit it.
>
> It has happened once in the past, and whether it is allowed depends on
> whether “follow the procedures of Bylaws Section 4.1
>
> as closely as possible” is merely referring to election procedures, or
> also candidate qualifications.
>
>
>
> This ambiguity was discussed during the spring CA/Browser Forum
> Face-to-face meeting, and the consensus was that we should
>
> update the Bylaws to clarify that re-election is allowed, and the election
> process itself is sufficient to determine
>
> whether members want to retain the existing Chair and/or Vice Chair, or
> whether they want to vote for someone else.
>
> This is important because the pool of qualified and willing candidates is
> not particularly large.
>
>
>
> This ballot retains the existing prohibition on re-election for Forum
> Chairs and Vice Chairs.
>
>
>
> — 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 —
>
>
>
> The procedure for approval of this ballot is as follows:
>
>
>
> Discussion (7+ days)
>
>
>
> Start Time: 2022-07-20 2:45 PM Eastern (US)
>
>
>
> End Time: 2022-07-27 3:15 PM Eastern (US)
>
>
>
> Vote for approval (7 days)
>
>
>
> Start Time: 2022-07-27 3:15 PM Eastern (US)
>
>
>
> End Time: 2022-08-03 3:15 PM Eastern (US)
>
>
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] Draft CA/Browser Forum agenda - Thursday, January 20, 2021 at 11:30 am Eastern Time

[Ben Wilson via Public]

We might want to have an item and time allocated for the Network Security
Committee report, which will meet tomorrow.

On Sun, Jan 16, 2022 at 5:31 PM Dean Coclin via Public 
wrote:

> *Here is the draft agenda for the subject call*
>
> *CA/Browser Forum Agenda*
>
> *Time*
>
> *Start(ET)*
>
> *Stop*
>
> *Item*
>
> *Description*
>
> *Presenters*
>
> 0:02
>
> 11:30
>
> 11:32
>
> 1.
>
> Roll Call
>
> Dean
>
> 0:01
>
> 11:32
>
> 11:33
>
> 2.
>
> Read Antitrust Statement
>
> Jos
>
> 0:01
>
> 11:33
>
> 11:34
>
> 3.
>
> Review Agenda
>
> Dean
>
> 0:01
>
> 11:34
>
> 11:35
>
> 4.
>
> Approval of minutes of last call (Nov 11th and Jan 6th)
>
> Dean
>
> 0:05
>
> 11:35
>
> 11:40
>
> 5.
>
> Forum Infrastructure Subcommittee update
>
> Jos
>
> 0:05
>
> 11:40
>
> 11:45
>
> 6.
>
> Code Signing Certificate Working Group update
>
> Bruce
>
> 0:05
>
> 11:45
>
> 11:50
>
> 7.
>
> S/MIME Certificate Working Group update
>
> Stephen
>
> 0:05
>
> 11:50
>
> 11:55
>
> 8.
>
> Next F2F: Salt Lake City, Feb 22-24 2022. Wiki and hotel signups open
>
> Dean
>
> 0:04
>
> 11:55
>
> 11:59
>
> 9
>
> Any Other Business
>
> 0:01
>
> 11:59
>
> 12:00
>
> 10.
>
> Next call: Feb 3rd
>
> Adjourn
>
>
> F2F Meeting Schedule:
>
>- 2022
>   - Feb 22-24 – Salt Lake City, Utah
>   - June 6-8 – Poland (Note: Meeting dates are Mon-Weds and will be
>   followed by the Trusted Economy Forum on Weds-Thurs), MEETING IS 
> SUBJECT TO
>   CHANGE DUE TO RSA CONFERENCE MOVE TO THE SAME WEEK
>   - Oct 24-26 – Berlin (Note: Meeting dates are Mon-Weds and will be
>   followed by the CA Day and TSP event on Thurs/Fri)
>
>
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] Voting Period Begins: Ballot FORUM-17: Create Network Security Working Group

[Ben Wilson via Public]

Mozilla vote "YES" on Ballot FORUM-17.

On Thu, Dec 16, 2021 at 11:39 AM Ben Wilson  wrote:

> Ballot FORUM-17, Create Network Security Working Group, is proposed by
> Ben Wilson of Mozilla and endorsed by Tim Hollebeek of DigiCert and David
> Kluge of Google.
>
> The Voting Period for Ballot FORUM-17 begins today at 19:00 UTC and ends
> on 23-Dec-2021 at 19:00 UTC.
>
> *Overview*
>
> In January 2013 the CA/Browser Forum’s “Network and Certificate System
> Security Requirements” (NCSSRs) became effective. In June 2017, the Forum
> chartered a Network Security Working Group to re-visit the NCSSRs. That
> charter expired on June 19, 2018, and in October 2018, the Server
> Certificate Working Group (SCWG) established a Network Security
> Subcommittee (NetSec Subcommittee) to continue work on the NCSSRs.
>
> This ballot proposes to charter a new Network Security Working Group
> (NetSec WG) to replace the NetSec Subcommittee, to continue work on the
> NCSSRs, and to conduct any and all business related to improving the
> security of Certification Authorities.
>
> Following the passage of this ballot:
>
> 1. A new NetSec WG will be chartered under the CA/B Forum, pursuant to
> section 5.3.1 of the Bylaws;
> 2. The Charter of the SCWG will be amended to remove the NCSSRs from
> within the scope of the SCWG Charter;
> 3. The existing mailing list and other materials developed for the NetSec
> Subcommittee will be repurposed for use by the NetSec WG;
> 4. The NetSec WG will produce and maintain versions of the NCSSRs; and
> 5. The NetSec WG will make security-related recommendations to other Forum
> WGs for requirements or guidelines that are within their purview, i.e. the
> BRs/EVGs of the SCWG, the Baseline Requirements for Code Signing
> Certificates of the Code Signing Certificate Working Group (CSCWG) or
> guidelines adopted by the S/MIME Certificate Working Group (SMCWG).
>
> *--- MOTION BEGINS ---*
>
>
> The Charter of the Server Certificate Working Group, currently version
> 1.1, is amended by deleting references to the Network and Certificate
> System Security Requirements, so that the Scope section of the Charter will
> now read as follows:
>
> * SCOPE:* The authorized scope of the Server Certificate Working Group
> shall be as follows:
>
> 1. To specify Baseline Requirements, Extended Validation Guidelines, and
> other acceptable practices for the issuance and management of SSL/TLS
> server certificates used for authenticating servers accessible through the
> Internet.
>
> 2. To update such requirements and guidelines from time to time, in order
> to address both existing and emerging threats to online security, including
> responsibility for the maintenance of and future amendments to the current
> CA/Browser Forum Baseline Requirements and Extended Validation Guidelines.
>
> 3. To perform such other activities that are ancillary to the primary
> activities listed above.
>
> See
> https://github.com/cabforum/forum/commit/a55fd7d3939f4f24aa26e88399069afede2a1edf
>
> The CA/Browser Forum creates the Network Security Working Group and adopts
> the following Charter:
>
> *Network Security Working Group Charter*
>
> The Network Security Working Group (“NetSec WG”) is hereby created to
> perform the activities as specified in this Charter, subject to the terms
> and conditions of the CA/Browser Forum Bylaws (https://cabforum.org/bylaws/)
> and Intellectual Property Rights (IPR) Policy (
> https://cabforum.org/ipr-policy/), as such documents may change from time
> to time. This charter for the NetSec WG has been created according to CAB
> Forum Bylaw 5.3.1. In the event of a conflict between this Charter and any
> provision in either the Bylaws or the IPR Policy, the provision in the
> Bylaws or IPR Policy shall take precedence. The definitions found in the
> Forum’s Bylaws shall apply to capitalized terms in this Charter.
>
> *1. Scope* – The scope of work performed by the NetSec WG includes:
>
> 1. To modify and maintain the existing Network and Certificate System
> Security Requirements or a successor requirements document (NCSSRs);
> 2. To make recommendations for improvements to security controls in
> the requirements or guidelines adopted by other Forum WGs (e.g. see
> sections 5 and 6 of the Baseline Requirements);
> 3. To create new requirements, guidelines, or recommended best
> practices related to the security of CA operations;
> 4. To perform risk analyses, security analyses, and other types of
> reviews of threats and vulnerabilities applicable to CA operations involved
> in the issuance and maintenance of publicly trusted certificates (e.g.
> server certificates, code signing certificates, SMIME certificates, etc.);
> and
> 5. To perform other activities ancillary to the primary activities
> listed above.
>
> *2. Out of Scope* – The NetSec WG shall not adopt requirements,
> Guidelines, or Maintenance Guidelines concerning certificate profiles,
> validation processes, 

[cabfpub] Voting Period Begins: Ballot FORUM-17: Create Network Security Working Group

[Ben Wilson via Public]

Ballot FORUM-17, Create Network Security Working Group, is proposed by Ben
Wilson of Mozilla and endorsed by Tim Hollebeek of DigiCert and David Kluge
of Google.

The Voting Period for Ballot FORUM-17 begins today at 19:00 UTC and ends on
23-Dec-2021 at 19:00 UTC.

*Overview*

In January 2013 the CA/Browser Forum’s “Network and Certificate System
Security Requirements” (NCSSRs) became effective. In June 2017, the Forum
chartered a Network Security Working Group to re-visit the NCSSRs. That
charter expired on June 19, 2018, and in October 2018, the Server
Certificate Working Group (SCWG) established a Network Security
Subcommittee (NetSec Subcommittee) to continue work on the NCSSRs.

This ballot proposes to charter a new Network Security Working Group
(NetSec WG) to replace the NetSec Subcommittee, to continue work on the
NCSSRs, and to conduct any and all business related to improving the
security of Certification Authorities.

Following the passage of this ballot:

1. A new NetSec WG will be chartered under the CA/B Forum, pursuant to
section 5.3.1 of the Bylaws;
2. The Charter of the SCWG will be amended to remove the NCSSRs from within
the scope of the SCWG Charter;
3. The existing mailing list and other materials developed for the NetSec
Subcommittee will be repurposed for use by the NetSec WG;
4. The NetSec WG will produce and maintain versions of the NCSSRs; and
5. The NetSec WG will make security-related recommendations to other Forum
WGs for requirements or guidelines that are within their purview, i.e. the
BRs/EVGs of the SCWG, the Baseline Requirements for Code Signing
Certificates of the Code Signing Certificate Working Group (CSCWG) or
guidelines adopted by the S/MIME Certificate Working Group (SMCWG).

*--- MOTION BEGINS ---*


The Charter of the Server Certificate Working Group, currently version 1.1,
is amended by deleting references to the Network and Certificate System
Security Requirements, so that the Scope section of the Charter will now
read as follows:

* SCOPE:* The authorized scope of the Server Certificate Working Group
shall be as follows:

1. To specify Baseline Requirements, Extended Validation Guidelines, and
other acceptable practices for the issuance and management of SSL/TLS
server certificates used for authenticating servers accessible through the
Internet.

2. To update such requirements and guidelines from time to time, in order
to address both existing and emerging threats to online security, including
responsibility for the maintenance of and future amendments to the current
CA/Browser Forum Baseline Requirements and Extended Validation Guidelines.

3. To perform such other activities that are ancillary to the primary
activities listed above.

See
https://github.com/cabforum/forum/commit/a55fd7d3939f4f24aa26e88399069afede2a1edf

The CA/Browser Forum creates the Network Security Working Group and adopts
the following Charter:

*Network Security Working Group Charter*

The Network Security Working Group (“NetSec WG”) is hereby created to
perform the activities as specified in this Charter, subject to the terms
and conditions of the CA/Browser Forum Bylaws (https://cabforum.org/bylaws/)
and Intellectual Property Rights (IPR) Policy (
https://cabforum.org/ipr-policy/), as such documents may change from time
to time. This charter for the NetSec WG has been created according to CAB
Forum Bylaw 5.3.1. In the event of a conflict between this Charter and any
provision in either the Bylaws or the IPR Policy, the provision in the
Bylaws or IPR Policy shall take precedence. The definitions found in the
Forum’s Bylaws shall apply to capitalized terms in this Charter.

*1. Scope* – The scope of work performed by the NetSec WG includes:

1. To modify and maintain the existing Network and Certificate System
Security Requirements or a successor requirements document (NCSSRs);
2. To make recommendations for improvements to security controls in the
requirements or guidelines adopted by other Forum WGs (e.g. see sections 5
and 6 of the Baseline Requirements);
3. To create new requirements, guidelines, or recommended best
practices related to the security of CA operations;
4. To perform risk analyses, security analyses, and other types of
reviews of threats and vulnerabilities applicable to CA operations involved
in the issuance and maintenance of publicly trusted certificates (e.g.
server certificates, code signing certificates, SMIME certificates, etc.);
and
5. To perform other activities ancillary to the primary activities
listed above.

*2. Out of Scope* – The NetSec WG shall not adopt requirements, Guidelines,
or Maintenance Guidelines concerning certificate profiles, validation
processes, certificate issuance, certificate revocation, or subscriber
obligations, which are within the purview of the Server Certificate Working
Group (SCWG), the Code Signing Certificate Working Group (CSCWG), or the
S/MIME Certificate Working Group (SMCWG).

*3. End Date* – The NetSec 

[cabfpub] Discussion Period Begins on Ballot FORUM-17: Create Network Security Working Group

[Ben Wilson via Public]

The following ballot is proposed by Ben Wilson of Mozilla and endorsed by
Tim Hollebeek of DigiCert and David Kluge of Google.

*Ballot Forum-17: Create Network Security Working Group*

*Overview*

In January 2013 the CA/Browser Forum’s “Network and Certificate System
Security Requirements” (NCSSRs) became effective. In June 2017, the Forum
chartered a Network Security Working Group to re-visit the NCSSRs. That
charter expired on June 19, 2018, and in October 2018, the Server
Certificate Working Group (SCWG) established a Network Security
Subcommittee (NetSec Subcommittee) to continue work on the NCSSRs.

This ballot proposes to charter a new Network Security Working Group
(NetSec WG) to replace the NetSec Subcommittee, to continue work on the
NCSSRs, and to conduct any and all business related to improving the
security of Certification Authorities.

Following the passage of this ballot:

   1. A new NetSec WG will be chartered under the CA/B Forum, pursuant to
   section 5.3.1 of the Bylaws;
   2. The Charter of the SCWG will be amended to remove the NCSSRs from
   within the scope of the SCWG Charter;
   3. The existing mailing list and other materials developed for the
   NetSec Subcommittee will be repurposed for use by the NetSec WG;
   4. The NetSec WG will produce and maintain versions of the NCSSRs; and
   5. The NetSec WG will make security-related recommendations to other
   Forum WGs for requirements or guidelines that are within their purview,
   i.e. the BRs/EVGs of the SCWG, the Baseline Requirements for Code Signing
   Certificates of the Code Signing Certificate Working Group (CSCWG) or
   guidelines adopted by the S/MIME Certificate Working Group (SMCWG).

*--- MOTION BEGINS ---*

The Charter of the Server Certificate Working Group, currently version 1.1,
is amended by deleting references to the Network and Certificate System
Security Requirements, so that the Scope section of the Charter will now
read as follows:

*SCOPE:* The authorized scope of the Server Certificate Working Group shall
be as follows:

   1. To specify Baseline Requirements, Extended Validation Guidelines, and
   other acceptable practices for the issuance and management of SSL/TLS
   server certificates used for authenticating servers accessible through the
   Internet.

   2. To update such requirements and guidelines from time to time, in
   order to address both existing and emerging threats to online security,
   including responsibility for the maintenance of and future amendments to
   the current CA/Browser Forum Baseline Requirements and Extended Validation
   Guidelines.

   3. To perform such other activities that are ancillary to the primary
   activities listed above.

See
https://github.com/cabforum/forum/commit/a55fd7d3939f4f24aa26e88399069afede2a1edf

The CA/Browser Forum creates the Network Security Working Group and adopts
the following Charter:

*Network Security Working Group Charter*

The Network Security Working Group (“NetSec WG”) is hereby created to
perform the activities as specified in this Charter, subject to the terms
and conditions of the CA/Browser Forum Bylaws (https://cabforum.org/bylaws/)
and Intellectual Property Rights (IPR) Policy (
https://cabforum.org/ipr-policy/), as such documents may change from time
to time. This charter for the NetSec WG has been created according to CAB
Forum Bylaw 5.3.1. In the event of a conflict between this Charter and any
provision in either the Bylaws or the IPR Policy, the provision in the
Bylaws or IPR Policy shall take precedence. The definitions found in the
Forum’s Bylaws shall apply to capitalized terms in this Charter.

*1. Scope* – The scope of work performed by the NetSec WG includes:

1.   To modify and maintain the existing Network and Certificate System
Security Requirements or a successor requirements document (NCSSRs);

2.   To make recommendations for improvements to security controls in the
requirements or guidelines adopted by other Forum WGs (e.g. see sections 5
and 6 of the Baseline Requirements);

3.   To create new requirements, guidelines, or recommended best practices
related to the security of CA operations;

4.   To perform risk analyses, security analyses, and other types of
reviews of threats and vulnerabilities applicable to CA operations involved
in the issuance and maintenance of publicly trusted certificates (e.g.
server certificates, code signing certificates, SMIME certificates, etc.);
and

5.   To perform other activities ancillary to the primary activities listed
above.

*2. Out of Scope* – The NetSec WG shall not adopt requirements, Guidelines,
or Maintenance Guidelines concerning certificate profiles, validation
processes, certificate issuance, certificate revocation, or subscriber
obligations, which are within the purview of the Server Certificate Working
Group (SCWG), the Code Signing Certificate Working Group (CSCWG), or the
S/MIME Certificate Working Group (SMCWG).

*3. End Date* – The NetSec WG shall continue 

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

[Ben Wilson via Public]

Hi Dimitris,

Our IPR Policy is not perfect, so it doesn't have a solution for every
possible scenario. It was written with a goal of balancing the interests of
IP holders and the Forum membership. From the IPR Policy, "Working Groups
will ordinarily not approve a Guideline if they are aware that Essential
Claims exist that are not available on RF terms. Members are encouraged to
bring to the attention of the applicable Working Group any known patent or
pending patent applications of other organizations (Members or non-Members)
that might contain Essential Claims." (IPR Policy 2)  This means there is
an obligation (some might say it is only a moral obligation) on all members
(and hopefully notice to anyone else) to alert the Forum of any potential
IP conflicts. It is meant to discourage "submarine patents" that stay
hidden and are brought out only when someone in the industry starts to
implement an Essential Claim in the patent.

In the case of the proposed NetSec WG:

If the Member is a member of the NetSec WG, then they implicitly grant a
royalty-free license to the IP. (IPR Policy 3.1)
If the Member is not a member of the NetSec WG, then they could claim that
anybody implementing an Essential Claim is infringing on their IP.
As soon as the Forum is aware of a potential Essential Claim, then a
"Patent Advisory Group" will be convened to resolve the situation and
"avoid anticipated patent problems". (IPR Policy 7.1)

Notice: This is not legal advice. If you have any further concerns, please
consult your attorney. 

Ben


On Fri, Nov 19, 2021 at 4:40 AM Dimitris Zacharopoulos (HARICA) <
dzach...@harica.gr> wrote:

> On 19/11/2021 12:03 π.μ., Tim Hollebeek wrote:
>
> The problem is that you would forcing IPR review responsibilities onto a
> bunch of people who explicitly tried to avoid it by not joining the working
> group(s) in question.
>
>
>
> This is problematic because “IPR review” isn’t just a review – you’re
> granting IP rights if you don’t make a declaration.  This is exactly why
> some companies don’t join some groups – so they aren’t interested making IP
> grants or even disclosures for subject areas they don’t want to participate
> in.  And I don’t blame them … why do all that work for no benefit to their
> company?
>
>
>
> -Tim
>
>
> I naively thought that once an organization is being notified about a
> possible IP conflict, they MUST review in order to claim possible IP
> rights. Isn't this the process we follow at a specific WG level? What
> happens if a Member neglects to review a Maintenance Guideline and later
> finds out that they had IP rights that have made it into a Final Guideline?
>
> Just curious :)
>
>
> Dimitris.
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

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

[Ben Wilson via Public]

I'd like to get two endorsers for this ballot, unless people feel that
there are comments/concerns that still need to be resolved.

On Mon, Nov 15, 2021 at 9:28 AM Ben Wilson via Public 
wrote:

> I am striking the following from the proposal: "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." I don't think we need to get into any lower-level details
> in the charter.  That would leave the following in section 5: "5. Notice
> of proposed amendments to NCSSRs – 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." That way, a courtesy notice is provided
> to those WGs and everything still stays within the NetSec WG for purposes
> of the IPR Policy and adoption of the NCSSRs. I believe this is the
> cleanest way to move forward.
> Ben
>
> On Thu, Nov 11, 2021 at 5:33 PM Clint Wilson  wrote:
>
>> 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 <
>> public@cabforum.org> 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.
>>
>>
>&

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

[Ben Wilson via Public]

I am striking the following from the proposal: "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."
I don't think we need to get into any lower-level details in the charter.
That would leave the following in section 5: "5. Notice of proposed
amendments to NCSSRs – 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." That way, a courtesy notice is provided to those
WGs and everything still stays within the NetSec WG for purposes of the IPR
Policy and adoption of the NCSSRs. I believe this is the cleanest way to
move forward.
Ben

On Thu, Nov 11, 2021 at 5:33 PM Clint Wilson  wrote:

> 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 <
> public@cabforum.org> 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 

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

[Ben Wilson via Public]

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:
>>
>>
>>
>>1. NetSec WG produces and maintains versions of the NCSSRs
>>2. Individual WGs point to a specific version of the NCSSRs
>>3. 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 WG manages it’s dependency on the TLS BRs.
>>
>>
>>
>> However, that model might not be desirable in this case, as issuing
>> systems for CAs are almost certainly shared across the use cases, and
>> divergences among the WGs as to which version of the NCSSRs they reference
>> would put certificate issuers in a bit of a pickle.  The WebTrust audit
>> framework also might need to change, as it typically bundles the NCSSRs
>> into other audits and can’t easily deal with multiple relevant versions of
>> the NCSSRs.
>>
>>
>>
>> I wanted to bring this issue up so we can discuss potential solutions,
>> which might include potential modifications to this charter.  For example,
>> we may want to modify the voting structure and/or procedures to make sure
>> modifications to the NCSSRs have the support of all the downstream
>> consumers before the changes are approved, instead of having to deal with
>> that as a second step.  This would also avoid the other problem that the
>> NetSec working group has had, which is where changes are debated and
>> approved by NetSec, but then have to be relitigated at the Server Cert
>> level, often with a lot of wasted effort.  I hope that certain recent
>> changes mean that that problem has now been overtaken by events, but it
>> does seem like it would be more productive if everyone agreed across all
>> working groups on NCCSR updates before they’re approved, so that they can
>> be adopted in a uniform way.
>>
>>
>>
>> Any other thoughts or feedback?  I would love to hear other approaches
>> that might work, I just want to avoid having to deal with version skew
>> problems with the NCSSRs.
>>
>>
>>
>> It’s possible that longer term, the NetSec working group should grow up
>> to be the “Baseline Baseline” working group that was discussed during
>> governance reform, that is tasked with handling all

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

[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:
>
>
>
>1. NetSec WG produces and maintains versions of the NCSSRs
>2. Individual WGs point to a specific version of the NCSSRs
>3. 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 WG manages it’s dependency on the TLS BRs.
>
>
>
> However, that model might not be desirable in this case, as issuing
> systems for CAs are almost certainly shared across the use cases, and
> divergences among the WGs as to which version of the NCSSRs they reference
> would put certificate issuers in a bit of a pickle.  The WebTrust audit
> framework also might need to change, as it typically bundles the NCSSRs
> into other audits and can’t easily deal with multiple relevant versions of
> the NCSSRs.
>
>
>
> I wanted to bring this issue up so we can discuss potential solutions,
> which might include potential modifications to this charter.  For example,
> we may want to modify the voting structure and/or procedures to make sure
> modifications to the NCSSRs have the support of all the downstream
> consumers before the changes are approved, instead of having to deal with
> that as a second step.  This would also avoid the other problem that the
> NetSec working group has had, which is where changes are debated and
> approved by NetSec, but then have to be relitigated at the Server Cert
> level, often with a lot of wasted effort.  I hope that certain recent
> changes mean that that problem has now been overtaken by events, but it
> does seem like it would be more productive if everyone agreed across all
> working groups on NCCSR updates before they’re approved, so that they can
> be adopted in a uniform way.
>
>
>
> Any other thoughts or feedback?  I would love to hear other approaches
> that might work, I just want to avoid having to deal with version skew
> problems with the NCSSRs.
>
>
>
> It’s possible that longer term, the NetSec working group should grow up to
> be the “Baseline Baseline” working group that was discussed during
> governance reform, that is tasked with handling all of the cross-cutting
> concerns that are best handled in a coordinated manner across all of the
> working groups.  While each working group does have its own unique needs
> and needs to have the ability to maintain their own requirements, there are
> lots of other cases beyond the NCSSRs where uniformity is more important,
> and now that we’re close to having all the policies in 3647 format, it’s
> relatively straightforward to maintain them in this way.
>
>
>
> -Tim
>
>
>
> *From:* Public  *On Behalf Of *Ben Wilson
> via Public
> *Sent:* Thursday, October 28, 2021 12:35 PM
> *To:* CABforum1 
> *Subject:* [cabfpub] Draft Working Group Charter for Network Security WG
>
>
>
> All,
>
> Here is a draft charter for a Network Security Working Group.  Please
> provide your comments, and then we will finalize this work in the form of a
> Forum Ballot and Server Certificate WG Ballot.
>
> Thanks,
>
> Ben
>
>
>
> *Overview*
>
> In January 2013 the CA/Browser Forum’s “Network and Certificate System
> Security Requirements” (NCSSRs) became effective. In June 2017, the Forum
> chartered a Network Security Working Group to re-visit the NCSSRs. That
> charter expired on June 19, 2018, and in October 2018, the Server
> Certificate Working Group (SCWG) established a Network Security
> Subcommittee (NetSec Subcommittee) to continue work on the NCSSRs.
>
> This ballot proposes to cha

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

[Ben Wilson via Public]

Hi Tim,

Some of us in the Network Security subgroup discussed this today. Here is
some possible language to add as a new Section 5 of the Charter:

5. Applicability of new NCSSR versions - Once the NetSec WG has adopted a
new version of the NCSSRs, and it has completed IPR review without the
filing of an Exclusion Notice, other Chartered Working Groups may adopt
such new version and update the version of the NCSSRs that they reference.
Alternatively, they may choose not to reference an explicit version, in
which case such new version will be assumed to apply.

Ben

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:
>
>
>
>1. NetSec WG produces and maintains versions of the NCSSRs
>2. Individual WGs point to a specific version of the NCSSRs
>3. 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 WG manages it’s dependency on the TLS BRs.
>
>
>
> However, that model might not be desirable in this case, as issuing
> systems for CAs are almost certainly shared across the use cases, and
> divergences among the WGs as to which version of the NCSSRs they reference
> would put certificate issuers in a bit of a pickle.  The WebTrust audit
> framework also might need to change, as it typically bundles the NCSSRs
> into other audits and can’t easily deal with multiple relevant versions of
> the NCSSRs.
>
>
>
> I wanted to bring this issue up so we can discuss potential solutions,
> which might include potential modifications to this charter.  For example,
> we may want to modify the voting structure and/or procedures to make sure
> modifications to the NCSSRs have the support of all the downstream
> consumers before the changes are approved, instead of having to deal with
> that as a second step.  This would also avoid the other problem that the
> NetSec working group has had, which is where changes are debated and
> approved by NetSec, but then have to be relitigated at the Server Cert
> level, often with a lot of wasted effort.  I hope that certain recent
> changes mean that that problem has now been overtaken by events, but it
> does seem like it would be more productive if everyone agreed across all
> working groups on NCCSR updates before they’re approved, so that they can
> be adopted in a uniform way.
>
>
>
> Any other thoughts or feedback?  I would love to hear other approaches
> that might work, I just want to avoid having to deal with version skew
> problems with the NCSSRs.
>
>
>
> It’s possible that longer term, the NetSec working group should grow up to
> be the “Baseline Baseline” working group that was discussed during
> governance reform, that is tasked with handling all of the cross-cutting
> concerns that are best handled in a coordinated manner across all of the
> working groups.  While each working group does have its own unique needs
> and needs to have the ability to maintain their own requirements, there are
> lots of other cases beyond the NCSSRs where uniformity is more important,
> and now that we’re close to having all the policies in 3647 format, it’s
> relatively straightforward to maintain them in this way.
>
>
>
> -Tim
>
>
>
> *From:* Public  *On Behalf Of *Ben Wilson
> via Public
> *Sent:* Thursday, October 28, 2021 12:35 PM
> *To:* CABforum1 
> *Subject:* [cabfpub] Draft Working Group Charter for Network Security WG
>
>
>
> All,
>
> Here is a draft charter for a Network Security Working Group.  Please
> provide your comments, and then we will finalize this work in the form of a
> Forum Ballot and Server Certificate WG Ballot.
>
> Thanks,
>
> Ben
>
>
>
> *Overview*
>
> In January 2013 the CA/Browser Forum’s “Network and Certificate System
> Security Requirements” (NCSSRs) became effective. In June 2017, the Forum
> chartered a Network Security Working Group to re-visit the NCSSRs. That
> charter expired on June 19, 2018, and in October 2018, the Server
> Certificate Working Group (SCWG) established a Network Security
> Subcommittee (NetSec Subcommittee) to continue work on the NCSSRs.
>
> This ballot proposes to charter a new Network Security Working Group
> (NetSec WG) to replace the NetSec Subcommittee, to continue work on the
> NCSSRs, and to conduct any and all business related to improving the
> security of Certification Authorities.
>
> Following the passage of th

[cabfpub] Draft Working Group Charter for Network Security WG

[Ben Wilson via Public]

All,
Here is a draft charter for a Network Security Working Group.  Please
provide your comments, and then we will finalize this work in the form of a
Forum Ballot and Server Certificate WG Ballot.
Thanks,
Ben

Overview

In January 2013 the CA/Browser Forum’s “Network and Certificate System
Security Requirements” (NCSSRs) became effective. In June 2017, the Forum
chartered a Network Security Working Group to re-visit the NCSSRs. That
charter expired on June 19, 2018, and in October 2018, the Server
Certificate Working Group (SCWG) established a Network Security
Subcommittee (NetSec Subcommittee) to continue work on the NCSSRs.

This ballot proposes to charter a new Network Security Working Group
(NetSec WG) to replace the NetSec Subcommittee, to continue work on the
NCSSRs, and to conduct any and all business related to improving the
security of Certification Authorities.

Following the passage of this/these ballot(s):

   1.

   A new NetSec WG will be chartered under the CA/B Forum, pursuant to
   section 5.3.1 of the Bylaws;
   2.

   The SCWG’s existing NetSec Subcommittee will be dissolved by the SCWG
   and the Charter of the SCWG will be amended to note that work on the NCSSRs
   are within the authorized scope of the NetSec WG;
   3.

   The existing mailing list and other materials developed for the NetSec
   Subcommittee will be repurposed for use by the NetSec WG; and
   4.

   The Forum will develop a procedure to coordinate the NetSec WG’s
   adoption of security-related recommendations for requirements or guidelines
   that are within the purview of the other Forum WGs (the BRs/EVGs by the
   SCWG, Baseline Requirements for Code Signing Certificates of the CSCWG,
   etc.).

NetSec WG Charter

A chartered Working Group (“NetSec WG”) is created to perform the
activities as specified in this Charter, subject to the terms and
conditions of the CA/Browser Forum Bylaws (https://cabforum.org/bylaws/)
and Intellectual Property Rights (IPR) Policy (
https://cabforum.org/ipr-policy/), as such documents may change from time
to time. This charter for the NetSec WG has been created according to CAB
Forum Bylaw 5.3.1. In the event of a conflict between this Charter and any
provision in either the Bylaws or the IPR Policy, the provision in the
Bylaws or IPR Policy shall take precedence. The definitions found in the
Forum’s Bylaws shall apply to capitalized terms in this Charter.

1. Scope - The scope of work performed by the NetSec WG includes:

1.   To modify and maintain the existing Network and Certificate System
Security Requirements (NCSSRs), or a successor requirements document;

2.   To make recommendations for improvements to security controls in the
requirements or guidelines adopted by other Forum WGs (e.g. see sections 5
and 6 of the Baseline Requirements);

3.   To create new requirements, guidelines, and best practices related to
the security of CA operations;

4.   To perform risk analyses, security analyses, and other types of
reviews of threats and vulnerabilities applicable to CA operations involved
in the issuance and maintenance of publicly trusted certificates (e.g.
server certificates, code signing certificates, SMIME certificates, etc.);
and

5.   To perform other activities ancillary to the primary activities listed
above.

2. Out of Scope – The NetSec WG shall not adopt requirements, Guidelines,
or Maintenance Guidelines concerning certificate profiles, validation
processes, certificate issuance, certificate revocation, or subscriber
obligations.

3. End Date – The NetSec WG shall continue until it is dissolved by a vote
of the CA/B Forum.

4. Deliverables - The NetSec WG shall be responsible for delivering and
maintaining the NCSSRs and any other documents the group may choose to
develop and maintain.

5. Participation and Membership – Membership in the NetSec WG shall be
limited to Certificate Issuer Members and Certificate Consumer Members of
the Server Certificate Working Group, the Code Signing Certificate Working
Group, or the SMIME Certificate Working Group.

In accordance with the IPR Policy, Members that choose to participate in
the NetSec WG MUST declare their participation and shall do so prior to
participating. A Member must declare its participation in the NetSec WG by
requesting to be added to the mailing list. The Chair of the NetSec WG
shall establish a list for declarations of participation and manage it in
accordance with the Bylaws, the IPR Policy, and the IPR Agreement.

The NetSec WG shall  include Interested Parties and Associate Members as
defined in the Bylaws.

Resignation from the NetSec WG does not prevent a participant from
potentially having continuing obligations under the Forum’s IPR Policy or
any other document.

6. Voting Structure

The NetSec WG shall consist of two classes of voting members, Certificate
Issuers and Certificate Consumers. In order for a ballot to be adopted by
the NetSec WG, two-thirds or more of the votes cast by the Certificate

Re: [cabfpub] Code signing and Time stamping

[Ben Wilson via Public]

Just a few thoughts to move this conversation forward, and speaking as a
CSCWG interested party and not to advocate any position of Mozilla, I think
the answer depends on how strict or flexible the CABF wants to be as an
organization when it comes to interpreting the scope of a working group
charter.

It seems that the mention of time stamping in a code signing work product
would be allowed even under a strict interpretation.  While creating
standards for issuing and managing time stamping certificates would
certainly be out of scope with a flexible interpretation.

The Scope in the Charter does not expressly include or exclude the
assignment of a time stamping OID for time stamping certificates.
https://cabforum.org/2019/03/26/code-signing-certificate-wg-charter/#1-Scope

Included in the scope is "Version 1.0 Draft of November 19, 2015, Baseline
Requirements for the Issuance and Management of Publicly-Trusted Code
Signing Certificates (subject to the CSCWG making a written finding that
the provenance of such document is sufficiently covered by the Forum’s IPR
Policy)."  Time stamping was discussed in that draft, and I recall that the
CSCWG did make the required written finding of provenance.  Is the
assignment of a timestamping OID a logical outcome of the continued work on
that earlier document?

Ben



On Mon, Apr 19, 2021 at 2:31 PM Dean Coclin via Public 
wrote:

> A discussion on last week’s CA/B call about code signing and time stamping
> brought up a question as to whether the latter was in scope of the CSCWG
> charter (
> https://cabforum.org/2019/03/26/code-signing-certificate-wg-charter/).
>
>
>
> Bruce said there was no CP OID for time stamping and that the group wanted
> to create one IAW with the CA/B Forum registry. Ryan was concerned that
> this was outside the CSCWG charter as it was not specifically mentioned
> therein. Dimitris commented that it was included in charter scope 1a which
> pulls in the EV CS guidelines where time stamping is specified. Ryan did
> not seem convinced and asked that the discussion continue on the list.
>
>
>
> The working group has not had a chance to discuss this since the Forum
> meeting but plans to do so on the next call.
>
>
>
> I’ve included the CS Public list on this thread since the topic is of
> interest to members/observers there. If a respondent does not have posting
> rights, I can re-post for them.
>
>
>
> Dean
>
>
>
>
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

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

[Ben Wilson via Public]

Mozilla votes "yes"

On Thu, Oct 22, 2020 at 8:16 AM Mike Reilly (SECURITY) via Public <
public@cabforum.org> wrote:

> Microsoft votes “Yes” on Special Ballot Forum-16 : )  Thanks, Mike
>
>
>
> *From:* Public  *On Behalf Of *Dean Coclin
> via Public
> *Sent:* Wednesday, October 21, 2020 7:15 PM
> *To:* CABforum1 
> *Subject:* [EXTERNAL] [cabfpub] Voting begins on Special Ballot Forum-16:
> Election of CA/Browser Forum Vice Chair
>
>
>
> Voting begins on this ballot below:
>
>
>
>
> The following motion has been proposed by the CA/Browser Forum Chair
> Dimitris Zacharopoulos of HARICA.
> Purpose of Ballot
>
> This special ballot is to confirm the new Vice Chair of the CA/Browser
> Forum.
>
>
>
> --- MOTION BEGINS ---
>
>
> In accordance with Bylaw 4.1(c), *Karina Sirota* representing Microsoft
> is hereby elected Vice Chair of the CA/Browser Forum for a term commencing
> on November 1, 2020 and continuing through October 31, 2022.
>
> --- MOTION ENDS ---
>
>
>
> The procedure for approval of this ballot is as follows:
>
> *Special Ballot Forum-16 - Election of CA/Browser Forum Vice Chair*
>
> *Start time*
>
> *End time*
>
> Discussion (7 days)
>
> October 14, 2020 at 11:00 am Eastern Time
>
> October 21, 2020 at 11:00 am Eastern Time
>
> Vote for approval (7 days)
>
> October 21, 2020 at 11:00 am Eastern Time
>
> October 28, 2020 at 11:00 am Eastern Time
>
>
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

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

[Ben Wilson via Public]

Mozilla votes "Yes" on ballot Forum-15.

On Mon, Sep 14, 2020 at 9:47 AM Dimitris Zacharopoulos (HARICA) via Public <
public@cabforum.org> wrote:

>
> HARICA votes "yes" to ballot Forum-15.
>
>
> On 2020-09-14 6:11 μ.μ., Dimitris Zacharopoulos (HARICA) via Public wrote:
>
>
> Voting begins for Special Ballot Forum-15.
>
> Dimitris.
>
>
> On 2020-09-07 8:53 μ.μ., Dimitris Zacharopoulos (HARICA) wrote:
>
>
> The following motion has been proposed by the CA/Browser Forum Chair
> Dimitris Zacharopoulos of HARICA.
> Purpose of Ballot
>
> This special ballot is to confirm the new Chair of the CA/Browser Forum.
>
> --- MOTION BEGINS ---
>
> In accordance with Bylaw 4.1(c), *Dean Coclin* representing Digicert is
> hereby elected Chair of the CA/Browser Forum for a term commencing on
> November 1, 2020 and continuing through October 31, 2022.
>
> --- MOTION ENDS ---
>
>
> The procedure for approval of this ballot is as follows:
>
> *Special Ballot Forum-15 - Election of CA/Browser Forum Chair*
>
> *Start time*
>
> *End time*
> Discussion (7 days)
> September 7, 2020 at 11:00 am Eastern Time
>
> September 14, 2020 at 11:00 am Eastern Time
> Vote for approval (7 days)
>
> September 14, 2020 at 11:00 am Eastern Time
>
> September 21, 2020 at 11:00 am Eastern Time
>
>
>
>
> ___
> Public mailing 
> listPublic@cabforum.orghttps://lists.cabforum.org/mailman/listinfo/public
>
>
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
___
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

[Ben Wilson via Public]

 Mozilla votes YES on Forum-14 version 2.

On Tue, Jun 9, 2020 at 8:57 AM Doug Beattie via Public 
wrote:

>
>
> GlobalSign votes Yes to ballot Forum-14 v2.
>
>
>
> Doug
>
>
>
> *From:* Public  *On Behalf Of *Tim Hollebeek
> via Public
> *Sent:* Monday, June 8, 2020 4:52 PM
> *To:* CABforum1 
> *Subject:* [EXTERNAL][cabfpub] VOTING BEGINS: Ballot Forum-14 version 2:
> Creation of S/MIME Certificates Working Group
>
>
>
> 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
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] Voting Begins for ballot Forum-12 - Update CA/B Forum Bylaws

[Ben Wilson via Public]

Mozilla votes "Yes"

On Mon, May 18, 2020 at 9:30 AM Dimitris Zacharopoulos (HARICA) via Public <
public@cabforum.org> wrote:

> The following motion has been proposed by Dimitris Zacharopoulos of HARICA
> and endorsed by Mike Reilly of Microsoft and Tim Hollebeek of Digicert.
>
> *Purpose of 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 effectively. Most of these changes are described in the 
> “Issues
> with Bylaws to be addressed
> ”
> document.
>
> Here is a list of major changes:
>
>1. Clarified the use of the term “Member” so it is clear when we
>discuss about all Forum Members (which includes Associate Members and
>Interested Parties), and when we discuss about the “Voting Members”. Adding
>the word “Voting” in front of the word “Member” removes this ambiguity.
>Also, the term “Members” or “Forum Members” is now the union of “Voting
>Members”, “Associate Members” and “Interested Parties”.
>2. Added the term “Voting Representative” which is designated by each
>Member. Only votes submitted by Voting Representatives will be considered.
>3. Replaced “Forum wiki” with the properly defined term “Member Web
>Site”.
>4. Removed references for Webmaster in the definition of “Public Web
>Site” since it is repeated in section 5.2.
>5. Added the Photography Policy in Exhibit D.
>6. Clarify 4.1 (2) that Forum Members nominate representatives
>7. Allow Informative Changes to Guidelines
>8. In 5.3.1 require that a Certificate Issuer is trusted in the
>“latest” software produced by a Certificate Consumer
>9. In 4.1 the Chair is eligible to be elected as Chair after having
>vacated the position as Chair for at least one (1) term, instead of two (2)
>years.
>
> *-- 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.3.pdf).
>
> *NOTE:* There are three redline versions:
>
>1. PDF (attached as "CA-Browser Forum Bylaws v2.3-redline.pdf")
>2. DOCX (attached as "CA-Browser Forum Bylaws v2.3-redline.docx")
>3. GitHub redline available at
>
> https://github.com/cabforum/documents/compare/fc63be73323195abc4e462708ca0385e37b7043d..a94d136c6ddbd0024e9bdc70785aa71f1e2f6753#diff-c2f0349076f544cc0e9f059f30f21a85
>
> *-- MOTION ENDS --*
>
> The procedure for approval of this ballot is as follows:
>
> *Forum-12 - Update CA/B Forum Bylaws*
>
> *Start time (15:00 UTC)*
>
> *End time (15:00 UTC)*
>
> Discussion (14 days)
>
> 04 May 2020
>
> 18 May 2020
>
> Vote for approval (7 days)
>
> 18 May 2020
>
> 25 May 2020
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

[cabfpub] Data Reuse under BR 3.2.2.4.3 (Phone Contact with Domain Contact)

[Ben Wilson via Public]

All,
Section 3.2.2.4.3 of the BRs says, "CAs SHALL NOT perform validations using
this method after May 31, 2019. Completed validations using this method
SHALL continue to be valid for subsequent issuance per the applicable
certificate data reuse periods."  If that is 825 days, then would that be
until Aug. 20, 2021? If it isn't 825 days, then what should it be?
Thanks,
Ben
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Cancel CA/B Forum teleconference November 14, 2019

[Ben Wilson via Public]

I think it's the other way around.  Thanksgiving in the U.S. is on the 28th.

-Original Message-
From: Public  On Behalf Of Dimitris
Zacharopoulos (HARICA) via Public
Sent: Monday, November 11, 2019 12:23 AM
To: public@cabforum.org
Subject: [cabfpub] Cancel CA/B Forum teleconference November 14, 2019

Due to Thanksgiving holiday in the U.S. I am cancelling the meeting on
Thursday November 14, 2019.

Our next scheduled teleconference is November 28th.


Thank you,
Dimitris.
___
Public mailing list
Public@cabforum.org
https://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] [EXTERNAL] FW: Ballot FORUM-10: Re-charter Forum Infrastructure Working Group

[Ben Wilson via Public]

DigiCert votes YES on Ballot FORUM-10.

 

From: Public mailto:public-boun...@cabforum.org> 
> On Behalf Of Jos Purvis (jopurvis) via Public
Sent: Monday, September 30, 2019 11:27 AM
To: CA/B Forum Public List mailto:public@cabforum.org> >
Subject: [EXTERNAL][cabfpub] FW: Ballot FORUM-10: Re-charter Forum 
Infrastructure Working Group

 

The following ballot is proposed by Jos Purvis of Cisco, endorsed by Wayne 
Thayer of Mozilla and Ben Wilson of DigiCert. Voting begins at 2100 UTC 30 
September 2019 and runs through 2100 UTC 7 October 2019.

 

Ballot Forum-10: Re-charter Forum Infrastructure Work

Overview

The Forum Infrastructure Working Group (FIWG) was chartered during a period 
when the CABF Bylaws did not permit for the creation of subcommittees at the 
Forum level (only under a particular Working Group). Since the work the FIWG 
needed to undertake was pressing and covered the needs of the Forum as a whole, 
it was chartered as a Working Group to permit this work to begin under the 
existing Bylaws.

With the completion of the recent Bylaws changes, subcommittees may now be 
constructed at the Forum level. In addition, the recent changes to Bylaws and 
membership have identified a hole by which membership in the FIWG could be used 
to “back-door” membership in the Forum as a whole, an unintended consequence 
worth squashing.

This ballot, therefore, lays down the existing FIWG and immediately re-charters 
a Forum Infrastructure Subcommittee to continue its work.

 

Gory Details

24 hours after this ballot passes the following will occur:

1.   The existing Forum Infrastructure Working Group will be dissolved per 
the Bylaws section 5.3.2 item 3.

2.  A new Infrastructure Subcommittee will be chartered under the CA/B 
Forum, per the Bylaws section 5.6, with the Charter of that Subcommittee as 
described below.

3.  The existing mailing list for the FIWG will be repurposed for the use 
of the Subcommittee, following an announcement to that end on the existing FIWG 
mailer.

4.  The existing wiki pages from the FIWG will be archived, and a new space 
created for the Subcommittee's use under the main Forum namespace.

 

Forum Infrastructure Subcommittee (FIS) Charter

Scope - The authorized scope of the Forum Infrastructure Subcommittee shall be 
as follows:

· To oversee the acquisition, operation, and maintenance of the common 
CA/Browser Forum website and wiki resources;

· To coordinate updates to public and Forum-facing web and wiki content 
in support of the Forum Webmaster role established in the Bylaws;

· To create and manage the division of access and content spaces 
required to help ensure the separation of the work of various Working Groups 
and accompanying IP commitments, as described in the Forum’s IPR Policy;

· To manage the technical means of production of guidelines and other 
documents produced by the Forum's subcommittees;

· To manage the Forum-level email lists and to offer management of 
working-group and subcommittee mailing lists as needed in support of the Forum 
List Manager role established in the Bylaws;

· To perform other activities ancillary to the primary activities 
listed above.

End Date - This Subcommittee shall continue until it is dissolved by a vote of 
the CA/B Forum.

Deliverables - The Forum Infrastructure Subcommittee shall be responsible for 
delivering wiki and mailing list services to the Forum on an ongoing basis, and 
supplying access to these and to the management tools for these as is 
appropriate and required by the Forum. The subcommittee shall not propose any 
changes to the Bylaws or IPR agreements itself: where issues with these are 
identified, they may be redirected to the Forum as a whole or to appropriate 
subcommittees or working groups for further consideration.

Participation - Any member of the CAB Forum is eligible and may declare their 
participation in the Forum Infrastructure Subcommittee by requesting to be 
added to the mailing list. 

Chair - Jos Purvis shall be the initial Chair of the Forum Infrastructure 
Subcommittee. The Chair shall not have a fixed term, but the Subcommittee may 
change its Chair from time to time by consensus of the Members participating in 
the Subcommittee or by voting method chosen by the Members by consensus.

Communication - Subcommittee communications and documents shall be posted on 
mailing-lists where the mail-archives are publicly accessible, and the 
Subcommittee shall publish minutes of its meetings to the Forum wiki.

Effect of Forum Bylaws Amendment for Subcommittees - In the event the Forum 
Bylaws are amended to add or modify general rules governing Forum Subcommittees 
and how they operate (“General Rules”), the provisions of the General Rules 
shall take precedence over this charter.

 

Key Dates


Ballot Discussion Begins

20 Sept 2019 21:00 UTC


Ballot Discussion Concludes

27 Sept 2019 21:00 UTC


Ballot Vote Begins

[cabfpub] Voting Begins: Ballot FORUM-8: Charter to Establish a Code Signing Certificate Working Group

[Ben Wilson via Public]

I hereby announce that Voting Begins on the following ballot and that DigiCert 
affirmatively votes "Yes":

 

 

Ballot FORUM-8: Charter to Establish a Code Signing Certificate Working Group

 

Purpose of Ballot

 

It is proposed that the Forum establish a working group to adopt and maintain a 
policy, framework, and set of standards related to the issuance and management 
of code signing certificates by a third-party Certificate Issuer, rather than 
by the platform supplier (i.e. Certificate Consumer) itself. The work would be 
based on the Forum's prior adoption of the EV Code Signing Guidelines, version 
1.4, (Ballot 172; 5 July 2016), and additional work by Forum members who 
expressly agreed to operate pursuant to the Forum's IPR Policy, between 2013 
and 2015, which resulted in a failed proposal to adopt a set of baseline 
requirements for the issuance and management of code signing certificates 
(https://cabforum.org/wp-content/uploads/Code-Signing-Requirements-2015-11-19.pdf;
 https://cabforum.org/2015/12/17/ballot-158).

 

It is proposed by Ben Wilson of DigiCert and endorsed by Mike Reilly of 
Microsoft and Bruce Morton of Entrust Datacard that the Forum charter a working 
group to operate in accordance with the Scope and other provisions that follow. 
 This Charter will take effect upon approval of the CAB Forum by ballot 
conducted in accordance with Bylaw 5.3. 

  

- BALLOT BEGINS -

 

Code Signing Certificate Working Group Charter

 

Introduction

 

This introduction provides general information and context with an intent to 
assist the interpretation of this Charter.  

 

A code signing certificate contains the public key corresponding to a private 
key that is used by a person or organization to digitally sign data-such data 
usually containing instructions (i.e. "code") for hardware to perform certain 
tasks. A code signing certificate can be identified by the existence of an 
Extended Key Usage (EKU) Object Identifier (OID) of 1.3.6.1.5.5.7.3.3. 

 

The objective of a code signing certificate is to provide a cryptographic way 
to identify the source of code. There are a variety of functional models and 
use cases whereby a code signing certificate is issued by a Certificate Issuer 
to a Subscriber for use in signing code that will run on a particular computing 
platform or group of platforms. (Each platform supplier determines how a chain 
between a trusted root CA certificate and the code signing certificate will be 
created and verified.) 

 

The primary use case under consideration for the working group is a model 
whereby the platform supplier accepts code signing certificates issued by a 
third-party Certificate Issuer. A common example of this model is Microsoft's 
Authenticode, although others exist.  

 

Other functional models include those which allow developers to self-sign code 
and those in which the platform supplier manages the code signing or 
certificate issuance process, and these models are expressly excluded from the 
working group's mandate. Common examples of these models that are expressly 
excluded from the scope of guidelines to be promulgated by the working group 
are Apple's Developer ID program and Google's Android.

 


Chartering of the Code Signing Certificate Working Group


 

Upon approval of the CAB Forum by ballot, the Code Signing Certificate Working 
Group ("CSCWG") 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. In the event of a conflict between this Charter and any provision 
in either the Bylaws or the IPR Policy, the provision in the Bylaws or IPR 
Policy SHALL take precedence. The definitions found in the Forum's Bylaws SHALL 
apply to capitalized terms in this Charter.  

 


1 Scope


 

The authorized scope of the CSCWG SHALL be to discuss, adopt, and maintain 
policies, frameworks, and sets of standards related to the issuance and 
management of code signing certificates by third-party Certificate Issuers 
under a publicly trusted root (and not code signing certificates issued under a 
private root CA), limited as follows:

 

a.  EV Code Signing Guidelines, v. 1.4 and subsequent versions
b.  Version 1.0 Draft of November 19, 2015, Baseline Requirements for the 
Issuance and Management of Publicly-Trusted Code Signing Certificates (subject 
to the CSCWG making a written finding that the provenance of such document is 
sufficiently covered by the Forum's IPR Policy) 
c.  Verification requirements for issuance/renewal of code signing 
certificates
d.  Subscriber protection of private keys, including keys stored in the 
cloud
e.  Certificate issuance and revocation
f.  Requirements/controls on use of code signing certificates
g.  Mechanisms to engage with AV vendors, researchers, and others regarding 
signed malware

Re: [cabfpub] Ballot FORUM-8: Charter to Establish a Code Signing Certificate Working Group

[Ben Wilson via Public]

I feel that I’ve followed the ballot rules, and I am assuming that this is a 
valid ballot with the comment period ending and voting beginning Friday, 
1-March-2019 at 0100 UTC.

 

From: Public  On Behalf Of Ben Wilson via Public
Sent: Friday, February 22, 2019 9:17 AM
To: Dimitris Zacharopoulos (HARICA) ; CA/Browser Forum 
Public Discussion List 
Subject: Re: [cabfpub] Ballot FORUM-8: Charter to Establish a Code Signing 
Certificate Working Group

 

Duly noted.  You’ll notice that it is a copy-from-Word/paste-to-Outlook 
automatic renumbering issue. See corrections below where I replaced automatic 
numbering with bullets.  

 

From: Dimitris Zacharopoulos (HARICA) mailto:dzach...@harica.gr> > 
Sent: Friday, February 22, 2019 3:35 AM
To: Ben Wilson mailto:ben.wil...@digicert.com> >; 
CA/Browser Forum Public Discussion List mailto:public@cabforum.org> >
Subject: Re: [cabfpub] Ballot FORUM-8: Charter to Establish a Code Signing 
Certificate Working Group

 


Ben,

There is an issue with numbered items in sections 4.2.1 and 4.2.2. You need to 
restart the numbering.


Thanks you,
Dimitris.


On 22/2/2019 2:00 π.μ., Ben Wilson via Public wrote:

Ballot FORUM-8: Charter to Establish a Code Signing Certificate Working Group

 

Purpose of Ballot

 

It is proposed that the Forum establish a working group to adopt and maintain a 
policy, framework, and set of standards related to the issuance and management 
of code signing certificates by a third-party Certificate Issuer, rather than 
by the platform supplier (i.e. Certificate Consumer) itself. The work would be 
based on the Forum’s prior adoption of the EV Code Signing Guidelines, version 
1.4, (Ballot 172; 5 July 2016), and additional work by Forum members who 
expressly agreed to operate pursuant to the Forum’s IPR Policy, between 2013 
and 2015, which resulted in a failed proposal to adopt a set of baseline 
requirements for the issuance and management of code signing certificates ( 
<https://clicktime.symantec.com/3BwAqVsiySWfvhgtcRLP3j17Vc?u=https%3A%2F%2Fcabforum.org%2Fwp-content%2Fuploads%2FCode-Signing-Requirements-2015-11-19.pdf>
 
https://cabforum.org/wp-content/uploads/Code-Signing-Requirements-2015-11-19.pdf;
  
<https://clicktime.symantec.com/3A2hTbYY7usubBPRGpqmBuN7Vc?u=https%3A%2F%2Fcabforum.org%2F2015%2F12%2F17%2Fballot-158>
 https://cabforum.org/2015/12/17/ballot-158).

 

It is proposed by Ben Wilson of DigiCert and endorsed by Mike Reilly of 
Microsoft and Bruce Morton of Entrust Datacard that the Forum charter a working 
group to operate in accordance with the Scope and other provisions that follow. 
 This Charter will take effect upon approval of the CAB Forum by ballot 
conducted in accordance with Bylaw 5.3. 

  

— BALLOT BEGINS —

 

Code Signing Certificate Working Group Charter

 

Introduction

 

This introduction provides general information and context with an intent to 
assist the interpretation of this Charter.  

 

A code signing certificate contains the public key corresponding to a private 
key that is used by a person or organization to digitally sign data—such data 
usually containing instructions (i.e. “code”) for hardware to perform certain 
tasks. A code signing certificate can be identified by the existence of an 
Extended Key Usage (EKU) Object Identifier (OID) of 1.3.6.1.5.5.7.3.3. 

 

The objective of a code signing certificate is to provide a cryptographic way 
to identify the source of code. There are a variety of functional models and 
use cases whereby a code signing certificate is issued by a Certificate Issuer 
to a Subscriber for use in signing code that will run on a particular computing 
platform or group of platforms. (Each platform supplier determines how a chain 
between a trusted root CA certificate and the code signing certificate will be 
created and verified.) 

 

The primary use case under consideration for the working group is a model 
whereby the platform supplier accepts code signing certificates issued by a 
third-party Certificate Issuer. A common example of this model is Microsoft’s 
Authenticode, although others exist.  

 

Other functional models include those which allow developers to self-sign code 
and those in which the platform supplier manages the code signing or 
certificate issuance process, and these models are expressly excluded from the 
working group’s mandate. Common examples of these models that are expressly 
excluded from the scope of guidelines to be promulgated by the working group 
are Apple’s Developer ID program and Google’s Android.

 


Chartering of the Code Signing Certificate Working Group


 

Upon approval of the CAB Forum by ballot, the Code Signing Certificate Working 
Group (“CSCWG”) 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. In t

[cabfpub] Ballot FORUM-8: Charter to Establish a Code Signing Certificate Working Group

[Ben Wilson via Public]

Ballot FORUM-8: Charter to Establish a Code Signing Certificate Working Group



Purpose of Ballot



It is proposed that the Forum establish a working group to adopt and maintain a 
policy, framework, and set of standards related to the issuance and management 
of code signing certificates by a third-party Certificate Issuer, rather than 
by the platform supplier (i.e. Certificate Consumer) itself. The work would be 
based on the Forum's prior adoption of the EV Code Signing Guidelines, version 
1.4, (Ballot 172; 5 July 2016), and additional work by Forum members who 
expressly agreed to operate pursuant to the Forum's IPR Policy, between 2013 
and 2015, which resulted in a failed proposal to adopt a set of baseline 
requirements for the issuance and management of code signing certificates 
(https://cabforum.org/wp-content/uploads/Code-Signing-Requirements-2015-11-19.pdf;
 https://cabforum.org/2015/12/17/ballot-158).



It is proposed by Ben Wilson of DigiCert and endorsed by Mike Reilly of 
Microsoft and Bruce Morton of Entrust Datacard that the Forum charter a working 
group to operate in accordance with the Scope and other provisions that follow. 
 This Charter will take effect upon approval of the CAB Forum by ballot 
conducted in accordance with Bylaw 5.3.



- BALLOT BEGINS -



Code Signing Certificate Working Group Charter



Introduction



This introduction provides general information and context with an intent to 
assist the interpretation of this Charter.



A code signing certificate contains the public key corresponding to a private 
key that is used by a person or organization to digitally sign data-such data 
usually containing instructions (i.e. "code") for hardware to perform certain 
tasks. A code signing certificate can be identified by the existence of an 
Extended Key Usage (EKU) Object Identifier (OID) of 1.3.6.1.5.5.7.3.3.



The objective of a code signing certificate is to provide a cryptographic way 
to identify the source of code. There are a variety of functional models and 
use cases whereby a code signing certificate is issued by a Certificate Issuer 
to a Subscriber for use in signing code that will run on a particular computing 
platform or group of platforms. (Each platform supplier determines how a chain 
between a trusted root CA certificate and the code signing certificate will be 
created and verified.)



The primary use case under consideration for the working group is a model 
whereby the platform supplier accepts code signing certificates issued by a 
third-party Certificate Issuer. A common example of this model is Microsoft's 
Authenticode, although others exist.



Other functional models include those which allow developers to self-sign code 
and those in which the platform supplier manages the code signing or 
certificate issuance process, and these models are expressly excluded from the 
working group's mandate. Common examples of these models that are expressly 
excluded from the scope of guidelines to be promulgated by the working group 
are Apple's Developer ID program and Google's Android.



Chartering of the Code Signing Certificate Working Group



A Chartered Working Group ("CWG") 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. This charter for the Code Signing 
Certificate Working Group has been created according to CAB Forum Bylaw 5.3.1. 
In the event of a conflict between this Charter and any provision in either the 
Bylaws or the IPR Policy, the provision in the Bylaws or IPR Policy SHALL take 
precedence. The definitions found in the Forum's Bylaws SHALL apply to 
capitalized terms in this Charter.



1.  Scope



The authorized scope of the CWG SHALL be to discuss, adopt, and maintain 
policies, frameworks, and sets of standards related to the issuance and 
management of code signing certificates by third-party Certificate Issuers 
under a publicly trusted root (and not code signing certificates issued under a 
private root CA), limited as follows:



a.  EV Code Signing Guidelines, v. 1.4 and subsequent versions
b.  Version 1.0 Draft of November 19, 2015, Baseline Requirements for the 
Issuance and Management of Publicly-Trusted Code Signing Certificates (subject 
to the CWG making a written finding that the provenance of such document is 
sufficiently covered by the Forum's IPR Policy)
c.  Verification requirements for issuance/renewal of code signing 
certificates
d.  Subscriber protection of private keys, including keys stored in the 
cloud
e.  Certificate issuance and revocation
f.  Requirements/controls on use of code signing certificates
g.  Mechanisms to engage with AV vendors, researchers, and others regarding 
signed malware
h.  Certificate profiles for code signing certificates and Issuing CA 
certificates 

[cabfpub] Draft Charter for Code Signing Certificate Working Group

[Ben Wilson via Public]

Here is a draft Code Signing Certificate WG Charter.  Please provide your 
comments.



https://docs.google.com/document/d/11mtnfCIeXJTX3EDz0wjV0-bigcjatC-kNJf0Uh6cMwk/edit?usp=sharing



Thanks,



Ben Wilson





___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

[cabfpub] Draft SMIME Working Group Charter

[Ben Wilson via Public]

Here is a draft SMIME WG Charter.  Please provide your comments.



https://docs.google.com/document/d/1vEswtzzMm0_G0ujoAT5ChiajyqfRfDTydG9Nmsc-eo4/edit?usp=sharing



Thanks,



Ben Wilson

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

[cabfpub] Code Signing and SMIME Working Group Charter Drafting

[Ben Wilson via Public]

As mentioned  on today's call - please contact me off-list if you're
interested in helping draft the charters for the two above-listed working
groups.



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

[cabfpub] Draft Bylaws WG Charter

[Ben Wilson via Public]

I've been meaning to get this out since the F2F - 

 

Ballot FORUM-__: Charter to Establish a Bylaws Working Group

 

Purpose of Ballot

As a necessary aspect of good governance, the CA/Browser Forum must maintain
its Bylaws to ensure that the organization meets the needs of its Members
and Interested Parties.  It is proposed by Ben Wilson of DigiCert and
endorsed by _  of _ and _ of  __ that the Forum charter a
working group to operate in accordance with the Scope and other provisions
that follow.  This Charter will take effect upon approval of the CAB Forum
by ballot conducted in accordance with section 5.3 of the Bylaws. 

  

- BALLOT BEGINS -

 

Bylaws Working Group Charter

 

A Chartered Working Group is ("CWG") 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 shall apply to capitalized terms in this Charter.  

 

1.  Scope

 

The authorized scope of the CWG shall be to discuss, evaluate, recommend,
draft, and present to the Forum-at-large proposals of changes to the Bylaws,
limited as follows:

 

(a) Review the criteria and process for membership in the CA/Browser Forum,
especially as it relates to membership in Working Groups of the Forum;

(b) Review the Bylaws requirements and provisions for the establishment of
subcommittees of Working Groups and their distinction from Working Groups of
the Forum;

(c) Review the requirements for establishing Working Groups and
subcommittees of the Forum, specifically the requirements for
records-keeping and management structures;

(d) Provide a set of specific recommendations to the Forum of improvements
or alterations to the Bylaws that would clarify, ease, or strengthen the
above;

(e) Respond with recommendations when tasked by other Chartered Working
Groups or the Forum Chair to provide recommended Bylaws changes for other
problems, or for the common interpretation of a provision, provided that
such request is in an email sent to the Public Mail List. 

 

2.  Out of Scope

 

The CWG SHALL NOT:

 

(a)  Act as arbiter or judge of Bylaws interpretations;

(b)  Revise or adopt changes to the Bylaws-it acts in an advisory
capacity only;

(c)   Create or adopt Final Guidelines or Final Maintenance Guidelines
as defined in the Bylaws and IPR Policy; or

(d)  Impose other requirements upon the rest of the Forum.

 

3.  Charter Expiration

 

The CWG is chartered for one (1) year, effective on ballot approval, after
which it expires.  The charter may be extended in accordance with Bylaw
5.3.2(b), or dissolved as specified in Bylaw 5.3.2(c).

 

4.  Personnel and Participation

 

a.  Initial Chairs and Contacts 

The proposer of the ballot, Ben Wilson, will act as chair of the CWG until
the first Working Group Teleconference, at which time the group will select
a chair and vice-chair pursuant to Section 5(a) below. The chair and
vice-chair will serve one-year term(s) or until they are replaced, resign,
or are otherwise disqualified.  

 

b.  Members Eligible to Participate

There are no eligibility requirements.  All Members may participate.
Membership or participation in the CWG does not alone qualify any
participant for Forum membership.

 

c.  Membership Declaration

In accordance with the IPR Policy, Members that choose to participate in the
CWG MUST declare their participation and must do so prior to participating.
The Chair of the CWG shall establish a list for declarations of
participation and manage it in accordance with the Bylaws, the IPR Policy,
and the IPR Agreement.

 

5.  Voting and Other Organizational Matters

 

(a) All decisions, including elections and other voting, will be made on a
consensus basis (and not pursuant to Bylaw 2.3 or 4.1). Where consensus
cannot be reached, then decisions shall be made by simple majority. For
clarity, simple majority means voting, egalitarian-based as a single class,
with one vote granted to each Member organization. A decision is adopted if
the number of votes cast meets Quorum, and the number of votes in favor
exceeds fifty percent (50%) of the votes cast. Quorum is defined as the
larger of three (3) or the average number of Member organizations that have
participated in the last three (3) CWG Meetings or Teleconferences (not
counting subcommittee meetings thereof). For transition purposes, if three
(3) meetings have not yet occurred, quorum is three (3). 

 

(b) Proponents of minority positions or recommendations may also present
their positions or recommendations to the Forum at large.  

 

(c) The CWG may form subcommittees in accordance with Section 5(a) above.

 

6.  Summary of Major Deliverables

 

The deliverables of the CWG are defined in the Scope section above. 

 

7.  Primary Means of 

[cabfpub] V.2.0 of CABF Bylaws

[Ben Wilson via Public]

The current version of the Bylaws (v.2.0) are posted on the Website here -
https://cabforum.org/bylaws/ 

 

The PDF and Word versions are here:  https://cabforum.org/wiki/Bylaws 

 

The Github version has been updated and is available here -
https://github.com/cabforum/documents/blob/master/docs/Bylaws.md  



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

[cabfpub] VOTING HAS STARTED Ballot Forum-2 - Chair and Vice-Chair Term Extensions

[Ben Wilson via Public]

VOTING HAS STARTED.

 

DigiCert votes "YES"

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ben Wilson
via Public
Sent: Wednesday, September 5, 2018 9:35 PM
To: CABFPub mailto:public@cabforum.org> >
Subject: [EXTERNAL][cabfpub] Ballot Forum-2 - Chair and Vice-Chair Term
Extensions

 

Ballot Forum-2 - Chair and Vice-Chair Term Extensions

 

Ben Wilson of DigiCert calls the following proposed ballot to be published
for discussion and comment by the CABF membership. 

 

Dimitris Zacharopoulos of HARICA and Jos Purvis of Cisco have endorsed the
proposed ballot.  

 

Explanation of Ballot: 

 

Kirk Hall was elected to a two-year term as Chair of the Forum by Ballot
177, and Ben Wilson was elected to a two-year term as Vice Chair of the
Forum by Ballot 178.  Their terms run from October 22, 2016 through October
21, 2018.  The Forum wishes to extend these terms by 10 days, to run through
October 31, 2018, in order that their successors can be elected to new
two-year terms starting on November 1, 2018, by separate ballots and so that
there will be no gap in leadership.

 

---Ballot Begins --- 

 

Kirk Hall's term as Chair of the CA/Browser Forum is hereby extended from
October 21, 2018 through October 31, 2018, and Ben Wilson's term as Vice
Chair of the CA/Browser Forum is hereby extended from October 21, 2018
through October 31, 2018. 

 

---Ballot Ends ---

 

The procedure for approval of this ballot is as follows:

 

Discussion Period (7 days)Start Time: 6-Sept-2018 16:00:00 UTC
End Time: 13-Sept-2018 16:00:00 UTC

 

Voting Period (7 days)   Start Time: 13-Sept-2018 16:00:00
UTC End Time: 20-Sept-2018 16:00:00 UTC

 

 



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

Re: [cabfpub] Forum Infrastructure Working Group: Initial Meeting and Declarations

[Ben Wilson via Public]

Let’s add you, too, there is no reason why a WG (and email distribution list) 
can’t have more than one representative from a member. Also, for this WG, I 
don’t think we’ll be voting on anything, other than as recommendations for the 
Forum at large.

 

From: Tim Hollebeek 
Sent: Tuesday, September 11, 2018 9:07 AM
To: Ben Wilson ; CA/Browser Forum Public Discussion 
List ; Jos Purvis (jopurvis) 
Subject: RE: [cabfpub] Forum Infrastructure Working Group: Initial Meeting and 
Declarations

 

Me.

 

I didn’t sign up on the wiki b/c DigiCert already joined through Ben’s signup.

 

-Tim

 

From: Public mailto:public-boun...@cabforum.org> 
> On Behalf Of Ben Wilson via Public
Sent: Tuesday, September 11, 2018 9:00 AM
To: CA/Browser Forum Public Discussion List mailto:public@cabforum.org> >; Jos Purvis (jopurvis) mailto:jopur...@cisco.com> >
Subject: Re: [cabfpub] Forum Infrastructure Working Group: Initial Meeting and 
Declarations

 

Just a reminder – 

 

Jos, Ryan, Wayne, Moudrick and Dimitris have signed up so far on the wiki for 
the Infrastructure WG.

 

Other takers?

 

From: Public mailto:public-boun...@cabforum.org> 
> On Behalf Of Ben Wilson via Public
Sent: Friday, August 31, 2018 12:00 PM
To: Jos Purvis (jopurvis) mailto:jopur...@cisco.com> >; 
CA/Browser Forum Public Discussion List mailto:public@cabforum.org> >
Subject: Re: [cabfpub] Forum Infrastructure Working Group: Initial Meeting and 
Declarations

 

Thanks, Jos.  I’ve signed up and indicated on Doodle that I’m pretty much 
available except Thursday mornings when we have some of our other CABF calls.

 

From: Public mailto:public-boun...@cabforum.org> 
> On Behalf Of Jos Purvis (jopurvis) via Public
Sent: Friday, August 31, 2018 10:31 AM
To: CA/B Forum Public List mailto:public@cabforum.org> >
Subject: [cabfpub] Forum Infrastructure Working Group: Initial Meeting and 
Declarations

 

Hello, all! The amount of enthusiasm and confidence in the ballot for the FIWG 
is really awesome…and slightly terrifying, given that I’ve got to get this 
thing off the ground!

 

I’ve created the initial wiki page for the working group, which right now 
contains the FIWG charter information. It also contains a table to use for 
declaring participation: per our IPR Policy, if you want to participate in the 
working group, you must declare your participation on the wiki page. We’ll be 
discussing the initial mailers and content for the working group on the first 
call.

 

Speaking of which, I’ve also created a poll to set the time for the working 
group meetings. The poll is below: it asks you to mark down possible and 
preferred times for the call. If you’re interested and have declared your 
organization’s participation on the wiki page, please hit the poll link below 
and declare your preference of times and dates. I’ll be closing the poll on 
Friday, 14 September and setting the meeting time thereafter.

 

Looking forward to talking with everyone as we get this going!

 

FIWG Wiki Page:

https://cabforum.org/wiki/Forum Infrastructure Working Group 
<https://cabforum.org/wiki/Forum%20Infrastructure%20Working%20Group> 

 

Meeting Time/Date Poll:

https://doodle.com/poll/7mss29k2cu3gr82n 

 

 

-- 
Jos Purvis (jopur...@cisco.com <mailto:jopur...@cisco.com> )
.:|:.:|:. cisco systems  | Cryptographic Services
PGP: 0xFD802FEE07D19105  | +1 919.991.9114 (desk)

 



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

Re: [cabfpub] Forum Infrastructure Working Group: Initial Meeting and Declarations

[Ben Wilson via Public]

Just a reminder – 

 

Jos, Ryan, Wayne, Moudrick and Dimitris have signed up so far on the wiki for 
the Infrastructure WG.

 

Other takers?

 

From: Public  On Behalf Of Ben Wilson via Public
Sent: Friday, August 31, 2018 12:00 PM
To: Jos Purvis (jopurvis) ; CA/Browser Forum Public 
Discussion List 
Subject: Re: [cabfpub] Forum Infrastructure Working Group: Initial Meeting and 
Declarations

 

Thanks, Jos.  I’ve signed up and indicated on Doodle that I’m pretty much 
available except Thursday mornings when we have some of our other CABF calls.

 

From: Public mailto:public-boun...@cabforum.org> 
> On Behalf Of Jos Purvis (jopurvis) via Public
Sent: Friday, August 31, 2018 10:31 AM
To: CA/B Forum Public List mailto:public@cabforum.org> >
Subject: [cabfpub] Forum Infrastructure Working Group: Initial Meeting and 
Declarations

 

Hello, all! The amount of enthusiasm and confidence in the ballot for the FIWG 
is really awesome…and slightly terrifying, given that I’ve got to get this 
thing off the ground!

 

I’ve created the initial wiki page for the working group, which right now 
contains the FIWG charter information. It also contains a table to use for 
declaring participation: per our IPR Policy, if you want to participate in the 
working group, you must declare your participation on the wiki page. We’ll be 
discussing the initial mailers and content for the working group on the first 
call.

 

Speaking of which, I’ve also created a poll to set the time for the working 
group meetings. The poll is below: it asks you to mark down possible and 
preferred times for the call. If you’re interested and have declared your 
organization’s participation on the wiki page, please hit the poll link below 
and declare your preference of times and dates. I’ll be closing the poll on 
Friday, 14 September and setting the meeting time thereafter.

 

Looking forward to talking with everyone as we get this going!

 

FIWG Wiki Page:

https://cabforum.org/wiki/Forum Infrastructure Working Group 
<https://cabforum.org/wiki/Forum%20Infrastructure%20Working%20Group> 

 

Meeting Time/Date Poll:

https://doodle.com/poll/7mss29k2cu3gr82n 

 

 

-- 
Jos Purvis (jopur...@cisco.com <mailto:jopur...@cisco.com> )
.:|:.:|:. cisco systems  | Cryptographic Services
PGP: 0xFD802FEE07D19105  | +1 919.991.9114 (desk)

 



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

Re: [cabfpub] [cabfman] Ballot Forum-3: Election of CA/Browser Forum Chair - ELECTION RESULTS

[Ben Wilson via Public]

Congratulations, Dimitris!  I look forward to supporting you in your new
role.

 

From: Public  On Behalf Of Wanko, Clemens via
Public
Sent: Thursday, September 6, 2018 11:35 AM
To: public@cabforum.org
Subject: Re: [cabfpub] [cabfman] Ballot Forum-3: Election of CA/Browser
Forum Chair - ELECTION RESULTS

 

Dear all,

the Election Committee herewith announces that the candidate for the Chair
of the CA/Browser Forum for a term commencing on November 1, 2018 and
continuing through October 31, 2020 who received the majority of the votes
is:

 

Dimitris Zacharopoulos

 

Congratulations to Dimitris and all the best wishes for your term as Chair
of the CA/Browser Forum!

 

Regards

Don & Clemens

 

 

On 30/08/18 16:00, Kirk Hall wrote:

> *Ballot Forum-3:   Election of CA/Browser Forum Chair - Term Nov. 1,

> 2018 - Oct. 31, 2020*

> 

> The voting period to elect a new Chair of the CA/Browser Forum is now 

> open. This Ballot is held In accordance with Bylaw 4.1.  We are 

> sending this notice to the Management list because of the email 

> addresses included.  We will also post a redacted version on the 

> Public list for information purposes.

> 

> *-Motion begins-*

> 

> The two candidates for Chair of the CA/Browser Forum for a term 

> commencing on November 1, 2018 and continuing through October 31, 2020
are:

> 

> 1.Ben Wilson

> 

> 2.Dimitris Zacharopoulos

> 

> _Please send your vote to the *two Election Committee members*

> directly_: Don Sheehy at  
donsheehy...@gmail.com 

> <  mailto:donsheehy...@gmail.com> and also
Clemens Wanko at 

>   clemens.wa...@tuv-austria.com <

mailto:clemens.wa...@tuv-austria.com>.

> You can either send them as separate emails, or as one email to both 

> committee members.  Please do */_NOT_/* send your vote to the Public 

> list or the Management list.

> 

> Each Member has one equal vote, regardless of whether its class of 

> membership is CA or Browser. If multiple votes are submitted by a 

> Member, the Election Committee will only count the last vote submitted 

> by a Member during the voting period.

> 

> All votes will be considered confidential information by the Election 

> Committee.

> 

> The candidate with the most votes on this ballot will be elected to 

> the position of Chair of the CA/Browser Forum for a term commencing on 

> November 1, 2018 and continuing through October 31, 2020.

> 

> *-Motion ends-*

> 

> The procedure for approval of this ballot is as follows:

> 

> Votes should be sent to the *_following Election Committee members

> directly_* - do /_not_/ send to the Public or Management list:

> 

>   donsheehy...@gmail.com <
 mailto:donsheehy...@gmail.com>; 

>   clemens.wa...@tuv-austria.com <
 mailto:clemens.wa...@tuv-austria.com>

> 

> Voting period: (7 days)

> 

> 

> Start Time: *Thursday, August 30, 2018 at 11:00 am Eastern Time*

> 

> 

> End Time: *Thursday, September 6, 2018 at 11:00 am Eastern Time*

> 

> The Election Committee will tally the votes and announce the candidate 

> with the most votes on the Public list (but will not announce the vote 

> totals or who voted for whom).

> 

> 

> 

> ___

> Management mailing list

>   managem...@cabforum.org

> https://cabforum.org/mailman/listinfo/management

> 

 



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

[cabfpub] Ballot Forum-2 - Chair and Vice-Chair Term Extensions

[Ben Wilson via Public]

Ballot Forum-2 - Chair and Vice-Chair Term Extensions

 

Ben Wilson of DigiCert calls the following proposed ballot to be published
for discussion and comment by the CABF membership. 

 

Dimitris Zacharopoulos of HARICA and Jos Purvis of Cisco have endorsed the
proposed ballot.  

 

Explanation of Ballot: 

 

Kirk Hall was elected to a two-year term as Chair of the Forum by Ballot
177, and Ben Wilson was elected to a two-year term as Vice Chair of the
Forum by Ballot 178.  Their terms run from October 22, 2016 through October
21, 2018.  The Forum wishes to extend these terms by 10 days, to run through
October 31, 2018, in order that their successors can be elected to new
two-year terms starting on November 1, 2018, by separate ballots and so that
there will be no gap in leadership.

 

---Ballot Begins --- 

 

Kirk Hall's term as Chair of the CA/Browser Forum is hereby extended from
October 21, 2018 through October 31, 2018, and Ben Wilson's term as Vice
Chair of the CA/Browser Forum is hereby extended from October 21, 2018
through October 31, 2018. 

 

---Ballot Ends ---

 

The procedure for approval of this ballot is as follows:

 

Discussion Period (7 days)Start Time: 6-Sept-2018 16:00:00 UTC
End Time: 13-Sept-2018 16:00:00 UTC

 

Voting Period (7 days)   Start Time: 13-Sept-2018 16:00:00
UTC End Time: 20-Sept-2018 16:00:00 UTC

 

 



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

Re: [cabfpub] Forum Infrastructure Working Group: Initial Meeting and Declarations

[Ben Wilson via Public]

Thanks, Jos.  I’ve signed up and indicated on Doodle that I’m pretty much 
available except Thursday mornings when we have some of our other CABF calls.

 

From: Public  On Behalf Of Jos Purvis (jopurvis) 
via Public
Sent: Friday, August 31, 2018 10:31 AM
To: CA/B Forum Public List 
Subject: [cabfpub] Forum Infrastructure Working Group: Initial Meeting and 
Declarations

 

Hello, all! The amount of enthusiasm and confidence in the ballot for the FIWG 
is really awesome…and slightly terrifying, given that I’ve got to get this 
thing off the ground!

 

I’ve created the initial wiki page for the working group, which right now 
contains the FIWG charter information. It also contains a table to use for 
declaring participation: per our IPR Policy, if you want to participate in the 
working group, you must declare your participation on the wiki page. We’ll be 
discussing the initial mailers and content for the working group on the first 
call.

 

Speaking of which, I’ve also created a poll to set the time for the working 
group meetings. The poll is below: it asks you to mark down possible and 
preferred times for the call. If you’re interested and have declared your 
organization’s participation on the wiki page, please hit the poll link below 
and declare your preference of times and dates. I’ll be closing the poll on 
Friday, 14 September and setting the meeting time thereafter.

 

Looking forward to talking with everyone as we get this going!

 

FIWG Wiki Page:

https://cabforum.org/wiki/Forum Infrastructure Working Group 
 

 

Meeting Time/Date Poll:

https://doodle.com/poll/7mss29k2cu3gr82n 

 

 

-- 
Jos Purvis (jopur...@cisco.com  )
.:|:.:|:. cisco systems  | Cryptographic Services
PGP: 0xFD802FEE07D19105  | +1 919.991.9114 (desk)

 



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

[cabfpub] CAB Forum Chair Candidate Statement

[Ben Wilson via Public]

Hi.

I'm Ben Wilson.

Many of you know me, but for those who may not, I am DigiCert's VP of
Compliance and have worked in PKI for approximately 20 years during which I
have been an active participant in the work of the CA/Browser Forum (CAB
Forum) and have held a variety of CABF leadership positions, including Chair
and Vice Chair, and I'd like for you to consider me for the position of
Chair again. Over the last couple of years, I have helped with the website
and maintenance of the guideline documents.  I've also helped run the Policy
Review, Network Security, and Governance Reform workgroups. I am an attorney
with several other relevant certifications, including MCSE, CISSP, and CISA.

I have a passion for PKI and am committed to staying current in our
ever-changing PKI industry. Because of this, I am deeply committed to seeing
the CAB Forum succeed in a positive, constructive way.  And, as a result of
our bylaw revisions, I would like to see the Forum grow and become more
relevant in the areas of code signing and client certificates. 

As Chair, I would be committed to following established procedures with
fairness.  I prefer that all voices be heard, and all sides considered,
before moving forward with solutions to the challenges that we face.  In
summary, I believe the Forum is a place where people can express their
opinions and seek solutions. 

It has been a great privilege to work with all of you, and I appreciate your
support in my candidacy for Forum Chair.

Sincerely yours,

Ben Wilson



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

[cabfpub] Final Minutes for Server Certificate Working Group Teleconference – 9 August 2018

[Ben Wilson via Public]

Final Minutes for Server Certificate Working Group Teleconference - 9 August
2018 

 

Attendees:   

 

1.  Roll Call.  The roll call occurred on the previous Forum teleconference.

 

2.  Read Antitrust Statement.  Reading of the Antitrust Statement occurred
on the previous Forum teleconference.  

 

3.  Review Agenda.  Agenda was approved.

 

4.  Approval of Minutes of teleconference of July 26, 2018.  The Minutes as
amended were approved, and will be posted to the Public list.

 

5.  Final list of Members, Associate Members, and Interested Parties - SCWG.
The updated list circulated by Kirk by email on August 6, 2018 was approved
and will be posted to the wiki and the Forum's website.  Kirk will make no
further efforts to contact former Forum members, who can apply if they are
interested in participating in the SCWG.

 

6.  Start of nomination period for CABF Chair and for SCWG Chair.  Kirk
noted that the nomination period for CABF Chair and for SCWG Chair had just
opened on August 9 at 11:00 am Eastern, and will run for two weeks through
August 23 at 11:00 am Eastern.  The terms will run from Nov. 1, 2018 through
Oct. 31, 2020.  Those who wish to be nominees can enter their names on the
Officer Elections page which has a link on the first page of the wiki.

 

7.  Status of SCWG Ballots to create Subcommittees (Validation, NetSec,
Certificate Policy/Policy Review).  Kirk noted that SCWG ballots were needed
to create new Validation, NetSec, and Certificate Policy / Policy Review
Subcommittees to replace the old Validation, NetSec, and Certificate Policy
/ Policy Review Working Groups of the Forum, which expire October 3.  Tim
said he had been busy with other projects but would come up with a ballot
for the Validation Subcommittee, and Dimitris said he would also for the
Certificate Policy Subcommittee.

 

8.  Plan for moving from Public mailing list to SCWG list.  Dimitris
previously proposed a plan for moving SCWG messages from the current Public
list to a new SCWG Public list in an email to the Forum members.  He
summarized the plan as follows:  We will try to automate the processes as
much as possible so Members can list and update their authorized
representatives who can post to the public lists and have access to the
management lists and the wiki.  During August, Members, Associate Members,
and Interested Parties will be required to provide their official
representatives and related email addresses to the Forum.  This information
will be included in a Google spreadsheet document, which will be maintained
by the Chair and Vice Chair.  Other tools will be developed, and any
difference between the official list and the current mailing list will be
reported to the officers.

 

We will start this process manually, and add features and automation over
time to cut down the administrative burden of making changes.  Members,
Associate Members, and Interested Parties will be required to post their
official representatives and related email addresses by August 31.  As of
September 1, if any former Member representative with posting privileges has
not been listed, he or she will continue to receive emails from the Public
list (but without posting rights, just like any other subscriber to the
Public list), and will be removed from the Management and Questions list.
The Forum's Public list and the SCWG Public list will be mirrored on
September 1 as there is only one Working Group at the present time.  Both
the Forum and SCWG will use the existing Management and Questions list until
there are other Chartered Working Groups, at which time we will create new
Management and Questions lists for each WG. The existing management and
questions list of the forum will then be copied to a SCWG management and
questions list.

 

Kirk asked if the Public and SCWG lists are mirrored now, and the answer was
no.  Kirk asked which list SCWG messages should be sent to in August, and
Dimitris suggested posting to both lists in August, and then only to the
SCWG list starting Sept. 1.

 

Ben asked if these changes would have an effect on or be affected by our IPR
Agreement.  Dimitris said no, the IPR Agreement was signed at the Forum
level and applies to all WG activity as well.  Once we have multiple WGs in
operation, then the critical issue as to applicability of the IPR Agreement
will depend on a particular Member's "participation" on a specific WG.

 

9.  Ballot Status.  No discussion.


10.  Any Other Business.  Tim said that the legacy Validation Working Group
had assigned "homework" to its members - they are to check with their
companies to determine how re-directs are handled for discussion of Method 6
and possible amendments.  They should communicate their findings back to the
Validation Working Group.

 

Kirk stated briefly how he thought the October F2F meeting in Shanghai would
be organized - the new Subcommittees would probably meet on Tuesday, and on
Wednesday and Thursday we would start with a plenary Forum 

[cabfpub] Final Minutes for CA/Browser Forum Teleconference – 9 August 2018

[Ben Wilson via Public]

Final Minutes for CA/Browser Forum Teleconference - 9 August 2018

 

Attendees: Arno Fiedler (D-TRUST), Atsushi Inaba (GlobalSign), Ben Wilson
(DigiCert), Corey Bonnell (Trustwave),Daymion Reynolds (GoDaddy), Dean
Coclin (DigiCert), Devon O'Brien (Google), Dimitris Zacharopoulos (HARICA),
Doug Beattie (GlobalSign), Frank Corday (Trustwave), Geoff Keating (Apple),
India Donald (FPKI), Joanna Fox (GoDaddy), Jos Purvis (Cisco), Kirk Hall
(Entrust), Leo Grove (SSL.com), Li-Chun Chen (Chunghwa Telecom), Mads
Henriksveen (BuyPass), Marcelo Silva (Visa), Neil Dunbar (Trustcor), Patrick
Tronnier (OATI), Robin Alden (ComodoCA), Ryan Sleevi (Google), Shelley
Brewer (DigiCert),Tim Hollebeek (DigiCert), Tim Shirley (Trustwave), Tomasz
Nowak (Opera), Trevoli Ponds-White (Amazon), Wayne Thayer (Mozilla), Wendy
Brown (Federal PKI). 

 

1.  Roll Call

 

2.  Read Antitrust Statement  

 

3.  Review Agenda.  Agenda was approved.

 

4.  Approval of Minutes of teleconference of July 26, 2018.  The Minutes as
amended were approved, and will be posted to the Public list.

 

5.  Final list of Members, Associate Members, and Interested Parties -
CA/Browser Forum.  The updated list circulated by Kirk by email on August 6,
2018 was approved and will be posted to the wiki and Forum's website.  Kirk
will make no further efforts to contact former Forum members, who can
reapply if they are interested in participating.

 

6.  Governance Change Working Group update (WG continued in Forum under
Bylaw 5.3.4 until Oct. 3, 2018).  Dean said the WG had met earlier in the
week, and would propose a ballot to extend the current terms of the Chair
and Vice Chair through October 31, 2018 to sync up with the terms of the new
officers.

 

7.  Ballot Status - see table at end of Agenda.  No discussion.

 

8.  Any Other Business.  There was no other business.

 

9.  Next call: August 23, 2018 at 11:00 Eastern Time

 

10.  Adjourn

 

 



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

[cabfpub] FW: Fond Farewell to Gerv Markham

[Ben Wilson via Public]

Below I have forwarded Kathleen Wilson's message from the Mozilla Dev Security 
Policy list.

It is with great sadness that we have learned the news of Gerv Markham's 
passing.

I uploaded a few photos of Gerv from a few of our social events to the wiki - 
https://cabforum.org/wiki/Gerv 

As Kathleen notes below, and as you'll recall from this past March, we gave 
Gerv a special commendation for his dedication and the important contributions 
that he made to our organization.  
https://cabforum.org/wp-content/uploads/Markham_Commendation_3-22-2018.pdf 

He will be deeply missed.

-Original Message-
From: dev-security-policy 
 On Behalf Of 
Kathleen Wilson via dev-security-policy
Sent: Sunday, July 29, 2018 10:24 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Fond Farewell to Gerv Markham

Dear Fellow Mozillians,

It is with deep sorrow that we share the news that our friend and colleague, 
Gerv Markham, passed away on July 27, 2018. Along with the many others whom he 
worked alongside over his time at Mozilla, we will remember Gerv as caring, 
honest, inquisitive, opinionated, energetic, and a lot of fun to work with! He 
enjoyed and looked forward to meeting with people in person, and loved diving 
into the details. He was often the first to pick up the phone to talk to people 
to get to the core of a situation. He was also quick to be helpful, going out 
of his way to provide assistance where needed. He would identify things that 
were in need of repair, meet with the owners to find out if they needed help, 
and dive right in to do the work.

Previously from Gerv: “It's been eighteen years since I first entered the world 
of Mozilla, on a program of constructing reduced layout test cases for early 
Gecko builds in order to earn a dino plushie (I got two!). Both I and the 
project have come a long way since then, but an ever-present companion has been 
my cancer, with which I was diagnosed in 2001.”

Eighteen years is a remarkable length of time to fight against incurable 
illness, and we are proud for the fighting Gerv managed to do throughout those 
years to advance Mozilla's mission.

Over the years of Gerv’s tenure with Mozilla, he worked on public policy, 
certificate authority (CA) root program, community governance, MPL, licensing, 
usability, security, and Bugzilla. He attended every CA/Browser Forum 
face-to-face meeting that he could, and the CA/Browser Forum extended the 
attached commendation to him.

It has been an honor to work with Gerv, and it is with very fond memories that 
we say goodbye to our wonderful friend and colleague, Gerv Markham.

Fond Farewell,

Kathleen Wilson, Wayne Thayer, JC Jones, and Chris Riley (among many more)


PS: Here is the text from the CA/Browser Forum Commendation that is mentioned 
above.
~~
The CA/Browser Forum and its members gratefully extend to Gervase Markham their 
heartfelt commendation and appreciation For his extraordinary leadership and 
skill as a founding member of the Forum in 2005 and as a Mozilla representative 
and a leading Forum participant from 2005–2018, and For his superb work in 
promoting higher standards for Certification Authorities, and For his ceaseless 
efforts to improve security for users on the internet, and For sharing his deep 
knowledge of TLS and PKI with his fellow Forum members, and For his constant 
innovation and improvement to the Mozilla processes applicable to CAs around 
the world, and For his skills during Forum meetings and teleconferences so that 
all could participate on an equal basis and members’ time was well spent, and 
For his ability to bridge differences of opinion among members to reach 
solutions that could be supported by all, and For his tact and diplomacy in 
helping Certification Authorities and Browsers meet their mutual goals, and For 
his patience, wit, sincerity, honesty, pleasant demeanor, and everlasting good 
cheer, and For his superior guidance, advice, and management style.
-- For these and many other accomplishments we hereby affirm our deep 
appreciation, commendation, and congratulations to Gerv, and sincerely extend 
our best wishes to him and his family. -- Dated this 22nd day of March, 2018.
ADOPTED UNANIMOUSLY BY THE MEMBERS OF THE CA / BROWSER FORUM ~~ 
___
dev-security-policy mailing list
dev-security-pol...@lists.mozilla.org



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

[cabfpub] Server Certificate Working Group List

[Ben Wilson via Public]

If you are interested in following the work of the Server Certificate Working 
Group, you can subscribe here:



https://cabforum.org/mailman/listinfo/servercert-wg



If you subscribe, and after a while you notice that you are not receiving 
emails sent to servercert...@cabforum.org 
with a subject line starting with [Servercert-wg], first check your spam 
folder, then contact me and I'll add you.



___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

[cabfpub] Server Certificate WG Mailing List

[Ben Wilson via Public]

If you have not subscribed to the Server Certificate WG Mailing List, please
go here:

https://cabforum.org/mailman/listinfo/servercert-wg 

Posting privileges will be granted to members, associate members, and
interested parties who have signed the IPR Agreement and formally declared
their participation in the WG.



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

[cabfpub] New Server Certificate Working Group

[Ben Wilson via Public]

Hi All,



As Kirk mentioned during the teleconference call yesterday, we are in the 
process of spinning up the Server Certificate Working Group and will hold our 
first meeting on July 12.  Kirk and I will be sending out a more formal 
announcement of that meeting and solicitation for participation.



However, given that the new Bylaws come into effect early next week, I felt it 
was important that we start the transition before then. I propose that the 
Forum's mechanism for formally declaring participation in the Server 
Certificate Working Group be that existing members and interested parties (who 
have signed the Agreement for IPR Policy v. 1.3) send an email to Kirk and me, 
respectively as Chair and Vice-Chair of the WG, and formally declare their 
participation in the WG. (I had contemplated that everyone might send their 
email to the public list, but I felt that all of those emails might clutter 
your inboxes.)



As a follow up task to this declaration, I'd ask that CABF members list the 
name of their organization here 
https://cabforum.org/wiki/Server%20Certificate%20Working%20Group.  If you are 
an interested party, we will add your name as a participant when we receive 
your email.



Also, everyone is welcome to subscribe to the WG's mailing list here - 
https://cabforum.org/mailman/listinfo/servercert-wg.



Thanks,



Ben

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] EXTERNAL: CAB Forum Countdown to IPR Agreement deadline

[Ben Wilson via Public]

Dear Carl,

You were on a page (Documents) that automatically indexes web site contents.  
I’ve deleted the version you complained about.  In any event, you should refer 
to the page located here https://cabforum.org/ipr-policy/ and let me know if 
you run into any other problems.

Yours truly,

Ben Wilson

 

From: Public  On Behalf Of Mehner, Carl via Public
Sent: Wednesday, April 18, 2018 4:10 PM
To: Virginia Fournier ; CA/Browser Forum Public Discussion 
List 
Subject: Re: [cabfpub] EXTERNAL: CAB Forum Countdown to IPR Agreement deadline

 

Hi Virginia,

 

How do interested parties 1) access the wiki to get the new IPR, 2) get 
notified when the IPR is expiring so that they don’t miss out on signing it in 
time? 3) How would an interested party upload the signed agreement if they 
cannot access the wiki?

 

For #1, is that answer that the definitive version is on the main site 
 
, not the wiki? If so, there seem to be two v1.3’s on that site, with different 
effective dates. (the email-lists site   
points to the older of the two versions and has no instructions on where to 
send the signed agreement).

 

 

Thanks, 

Carl Mehner

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Virginia 
Fournier via Public
Sent: Wednesday, April 18, 2018 1:53 PM
To: CA/Browser Forum Public Discussion List  >
Subject: EXTERNAL: [cabfpub] CAB Forum Countdown to IPR Agreement deadline

 

75 days until July 3, the deadline to get your IPR Agreement signed and 
submitted.

 

Here’s the wiki url, where you can download the IPR Policy v. 1.3 and the IPR 
Policy Agreement, and upload your signed agreement.  

 

https://www.cabforum.org/wiki/Intellectual%20Property%20Rights 

 

 

Don’t wait until the last minute!





Best regards,

 

Virginia Fournier

Senior Standards Counsel

 Apple Inc.

☏ 669-227-9595

✉︎ v...@apple.com  

 

 

 

 

 



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

[cabfpub] CP Review Working Group's GitHub Branch -Pull Request #84

[Ben Wilson via Public]

All,

The Policy Review Working Group has just completed its review of the Baseline 
Requirements in an attempt to clarify use of the term "CA", which sometimes can 
be ambiguous.  As you have been briefed several times, we chose the term "TSP" 
to refer to the legal entity that operates the CA, recognizing that the TSP may 
operate multiple CAs as well as other businesses.  To maintain consistency we 
decided to leave the term "CA" in as many as places as possible.

Please review the following Pull Request #84 and either respond to this thread 
or submit your comments to the branch/pull request-

https://github.com/cabforum/documents/pull/84.

Thanks,
CABF Policy Review Working Group


Ben Wilson, JD, CISA, CISSP
DigiCert VP Compliance

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Pre-Ballot 206 - Amendment to IPR Policy & Bylaws re Working Group Formation

[Ben Wilson via Public]

Here is a revised draft.

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Dimitris 
Zacharopoulos via Public
Sent: Thursday, January 11, 2018 8:53 AM
To: CA/Browser Forum Public Discussion List <public@cabforum.org>
Subject: Re: [cabfpub] Pre-Ballot 206 - Amendment to IPR Policy & Bylaws re 
Working Group Formation

 


I filled the attached in the governance WG on Tuesday about the Server 
Certificate Working Group Charter, which didn't make it in the version 
distributed by Ben.

These are some comments for definitions of Application Software Suppliers and 
Qualified Auditors. I also think we need to update the audit criteria for CAs 
so the WebTrust and ETSI are aligned.

Since we prefer to use the term "Browser Members", it would make sense to 
replace "Application Software Suppliers" in this charter with "Browsers", or 
replace "Browsers" with "Application Software Suppliers" (which doesn't sound 
very well).


Dimitris.

On 11/1/2018 7:21 πμ, Ben Wilson via Public wrote:

As a preface to tomorrow's discussion of the proposed Bylaw revisions, here is 
a synopsis of some of the proposed changes.  (The language in the following 
synopsis should not be considered a substitute for the actual language being 
considered, which is in the attached documents.)
 
1. Bylaws - New governance structure
* Keeps Forum as a general governing structure, but all work done and adopted 
in new, separate Working Groups (WG) that may have differing membership
* Membership in the Forum will be based on membership in a WG - Forum 
membership will include all members of all working groups.
* "Issuing CA" and "Root CA" now "Certificate Issuers" and "Browsers" are 
"Certificate Consumers", defined as "The member organization produces a 
software product, such as a browser, intended for use by the general public for 
relying upon certificates and is a member of a Working Group."
* WG membership could be CAs and browsers (like for the initial Server 
Certificate Working Group), but could have different membership categories for 
different WGs, based on the subject matter
* Voting at the Forum level (administrative issues, bylaws, creating new 
working groups) will still be two-thirds for Certificate Issuers and >50% for 
Certificate Consumers
* New WGs formed according to new charters approved by the Forum governing 
structure.  Each WG will have its own membership criteria and voting rules, to 
be established in the charter passed by the Forum.  All will be required to 
follow the same basic rules the Forum now follows as to public communications, 
IPR, Minutes, a Chair and Vice-Chair, allowing limited participation by 
Interested Parties
* WGs will each be bound by a form of IPR Agreement approved by the Forum, but 
only members of a WG will be bound by the IPR Agreement applicable to that WG- 
see below
* The WG gets to decide and vote on the content of its output, which does not 
come back to the Forum for approval.
* WGs can themselves create "subcommittees" of members, similar to what working 
groups of the Forum do today (Validation, Network Security, Policy Review will 
now be called "committees" or "sub-committees").  (Section 5.3.4 of the current 
draft bylaw provides that a legacy Working Group has the option of immediately 
terminating or continuing in effect without change for 6 months following these 
amendments to the Bylaws.)
* New governance structure will take effect as soon as governance rules and 
initial charter for a Server Certificate Working Group are passed by the Forum 
(there is no IPR Review Period).
* Other:  Ballot language will take precedence over Redline versions (but make 
sure both versions are consistent and based on the most recent version of the 
guidelines); and another provision proposes that in lieu of the current 
language in section 5.1.(a) ("after 2 weeks have elapsed since publication of 
the draft if no Forum Meeting or Forum Teleconference is imminent") instead, 
after 3 weeks, a member can request that minutes be published.
 
2. Initial Server Certificate Working Group, chartered under new governance 
structure
* Very similar to current scope of the Forum, membership and voting rules.  
Will take over current substantive work of the Forum.
* A proposed term of five (5) years
* Initial officers the same as those currently chairing the Forum (Kirk, Chair, 
and Ben, Vice-Chair)
* Voting the same as it is today (two-thirds for CAs and >50% for Browsers)
 
3. IPR Policy and Agreements
* Scope covers commitments Members undertake "as a condition of participation 
in CAB Forum Working Groups"
* Only the affirmative act of joining a Working Group (or otherwise agreeing to 
the licensing terms) obligates a Member to Royalty-Free (RF) Licensing 
obligations
* Chair still publishes Notice of Rev

Re: [cabfpub] No post of CABF minutes of Oct 12, 2017 Teleconference call

[Ben Wilson via Public]

I’ve  posted them now.    
https://cabforum.org/2017/10/12/2017-10-12-minutes/ 

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of realsky(CHT) via 
Public
Sent: Wednesday, January 10, 2018 6:31 PM
To: CA/Browser Forum Public Discussion List 
Subject: [cabfpub] No post of CABF minutes of Oct 12, 2017 Teleconference call

 

In  https://cabforum.org/2017/10/26/2017-10-26-minutes/, 

 

10.Other Business:

 

It said"the minutes of the last teleconference held on Thursday, October 
12, 2017, were approved."

 

But I found there are no minutes of October 12, 2017 teleconference  posted in 
https://cabforum.org/category/minutes/ as attached print screen for the URL.

 

 

  Li-Chun Chen
  Chunghwa Telecom 

 

 

 

 

本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 
如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任. 

Please be advised that this email message (including any attachments) contains 
confidential information and may be legally privileged. If you are not the 
intended recipient, please destroy this message and all attachments from your 
system and do not further collect, process, or use them. Chunghwa Telecom and 
all its subsidiaries and associated companies shall not be liable for the 
improper or incomplete transmission of the information contained in this email 
nor for any delay in its receipt or damage to your system. If you are the 
intended recipient, please protect the confidential and/or personal information 
contained in this email with due care. Any unauthorized use, disclosure or 
distribution of this message in whole or in part is strictly prohibited. Also, 
please self-inspect attachments and hyperlinks contained in this email to 
ensure the information security and to protect personal information.

 

 



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

Re: [cabfpub] Ballot 216: Update Discussion Period Process

[Ben Wilson via Public]

DigiCert votes “Yes” on Ballot 216

 

On Tue, Dec 12, 2017 at 1:51 PM, Gervase Markham via Public 
 > wrote:

[Updated endorsers, 2nd attempt. Timeline unchanged.]

Ballot 216: Update Discussion Period Process

Purpose of Ballot: The current voting procedures specify a "period of 
discussion", the duration of which is fixed before the ballot process begins. 
This ballot updates that to instead have the period of discussion be more 
flexible, to avoid it expiring while discussion is ongoing and thereby voting 
on a sub-optimal ballot.

The following motion has been proposed by Gervase Markham of Mozilla and 
endorsed by Tim Hollebeek of DigiCert and Ryan Sleevi of Google: 

-- MOTION BEGINS -- 

This ballot modifies the CAB Forum Bylaws.

In Section 2.3(c), replace the text:

"The discussion period then shall take place for at least seven but no more 
than 14 calendar days before votes are cast. The proposer of the ballot will 
designate the length of the discussion period, and each ballot shall clearly 
state the start and end dates and times (including time zone) for both the 
discussion period and the voting period."

with:

"The discussion period then shall take place for at least seven calendar days 
before votes are cast. At any time, a new version of the ballot (marked with a 
distinguishing version number) may be posted by the proposer in the same manner 
as the original. Once no new version of the ballot has been posted for seven 
calendar days, the proposer may end the discussion period and start the voting 
period by reposting the final version of the ballot and clearly indicating that 
voting is to begin, along with the start and end dates and times (including 
time zone) for the voting period. The ballot automatically fails if 21 calendar 
days elapse since the proposer last posted a version of the ballot and the 
voting period has not been started."

Similarly, in Section 2.4(b), replace the text:

"As described in Section 2.3(c), there will be a discussion period of at least 
seven but no more than 14 calendar days before votes are cast on a Draft 
Guideline Ballot, with the start and end dates of such discussion period 
clearly specified in the ballot."

with:

"As described in Section 2.3(c), there will be a discussion period of at least 
seven days before votes are cast on a Draft Guideline Ballot, with the start 
date of such discussion period clearly specified in the ballot. The discussion 
period shall end and the voting period shall commence also according to the 
procedure specified in Section 2.3(c)."

In Section 2.3(d) of the CAB Forum Bylaws, replace the text:

"Upon completion of the discussion period, Members shall have"

with:

"Upon commencement of the voting period, Members shall have"

Similarly, in Section 2.4(c), replace the text:

"As described in Section 2.3(d), upon completion of such discussion period, 
Members shall have"

with:

"As described in Section 2.3(d), upon commencement of the voting period, 
Members shall have"

-- MOTION ENDS -- 

The procedure for approval of this ballot is as follows: 


Start time (22:00 UTC) 

End time (22:00 UTC) 


Discussion (7 to 14 days) 

7 Dec

14 Dec


Vote for approval (7 days) 

14 Dec

21 Dec

Votes must be cast by posting an on-list reply to this thread on the Public 
list. A vote in favor of the motion must indicate a clear 'yes' in the 
response. A vote against must indicate a clear 'no' in the response. A vote to 
abstain must indicate a clear 'abstain' in the response. Unclear responses will 
not be counted. The latest vote received from any representative of a voting 
member before the close of the voting period will be counted. Voting members 
are listed here: https://cabforum.org/members/ 

In order for the motion to be adopted, two thirds or more of the votes cast by 
members in the CA category and greater than 50% of the votes cast by members in 
the browser category must be in favor. Quorum is shown on CA/Browser Forum 
wiki. Under Bylaw 2.2(g), at least the required quorum number must participate 
in the ballot for the ballot to be valid, either by voting in favor, voting 
against, or abstaining. 


___
Public mailing list
Public@cabforum.org  
https://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] Ballot 217: Sunset RFC 2527

[Ben Wilson via Public]

DigiCert votes "Yes" on Ballot 217

 

 

On 7 Dec 2017, at 16:52, Ryan Sleevi via Public  > wrote:

 

Ballot 217: Sunset RFC 2527

 

Purpose of Ballot: The Baseline Requirements and Extended Validation
Guidelines require that CA's disclosures of the Certificate Policy and/or
Certification Practice Statements include all of the material required by
either RFC 2527 or RFC 3647 and structured in accordance with RFC 2527 or
RFC 3647.

 



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

Re: [cabfpub] CAA working group description

[Ben Wilson via Public]

Let’s put this on the agenda for next CABF teleconference.

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Geoff Keating 
via Public
Sent: Monday, October 9, 2017 5:04 PM
To: Phillip ; CA/Browser Forum Public Discussion List 

Subject: Re: [cabfpub] CAA working group description

 

I tried to write the CABForum WG charter so that it did not include changes to 
the CAA specification itself; these should indeed be handled at the IETF level. 
 This WG is about adoption of CAA in the Baseline Requirements.  Some topics we 
might cover are:

 

- Requirement for DNSSEC checking—for example, we might extend the current 
requirements so that CAs obtain and retain a record of the NSEC/NSEC3 record 
proving a subdomain does not use DNSSEC, even if they don’t actually check the 
crypto

- Error handling—for example, perhaps repeated failure to find a record should 
be treated as if the record is missing, rather than the current interpretation 
where we treat it as if the record exists and allows issuance, or we might just 
go to fail-closed

- Adoption of any new IETF RFCs, which may need to be phased in

- Adoption of any new IETF Errata

 

I don’t think any of these apply at the IETF level; I’m sure the IETF is not 
going to specify a ‘what if you only wanted a little bit of DNSSEC’ 
configuration, I think the IETF RFC should specify fail-closed because that’s 
the only fully secure approach, and the IETF can’t specify adoption of their 
standards in the Baseline Requirements.





On 5 Oct 2017, at 11:09 am, Phillip via Public  > wrote:

 

I can well imagine a possibility where the IETF WG might leave some parts of 
the specification specified in less detail than would be desirable for 
compliance purposes and thus make work in CABForum desirable. But lets cross 
that bridge if we come to it.

 

What somewhat worries me is a situation in which I have ten CABForum members 
tell me that they really want X in a CABForum group and then I report that into 
the IETF WG and three people say they have other ideas and there being 3 of 
them and one of me, they represent the consensus. IETF process does allow for 
liasons and there might be an argument for a CABForum/IETF liason. But that 
does not seem like the right approach here.

 

 

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Thursday, October 5, 2017 1:52 PM
To: Jacob Hoffman-Andrews  
>; CA/Browser Forum Public Discussion List  >
Subject: Re: [cabfpub] CAA working group description

 

I agree with both Phillip and Jacob here. I think LAMPS is a great venue for 
working out the technical issues of discussion - and identifying where policy 
flexibility is needed or the challenges - and then bringing that as maybe one 
or two more ballots into the Forum. I think the technical clarifications and 
edge cases that we've seen discussed are totally within the realm of IETF's 
goals of interoperability, so we should try to use that as much as possible :)

 

The extent of Forum ballots seems like it may be adopting one or two more 
technical erratum (if interoperability issues arise and raised in IETF), and 
then potentially exploring adopting the newer version being proposed in LAMPS 
once completed.

 

On Thu, Oct 5, 2017 at 10:40 AM, Jacob Hoffman-Andrews via Public < 
 public@cabforum.org> wrote:

With respect, I would suggest that there is already a CAA working group: the 
IETF LAMPS WG at   
https://datatracker.ietf.org/wg/lamps/charter/. It has the advantage of being 
open for anyone to join and post, so CAs can more easily have conversations 
with Subscribers and Relying Parties. If half of the CAA conversation happens 
in LAMPS and half happens here, it will be harder for Subscribers and Relying 
Parties to fully participate.

 

I'd definitely encourage anyone in the CA/Browser Forum who is interested in 
CAA issues to join the LAMPS mailing list at  
 
https://www.ietf.org/mailman/listinfo/spasm (confusingly, the mailing list is 
named SPASM, a holdover from an earlier name).

 

I think it's likely there will be another ballot or two in the CA/Browser Forum 
clarifying some of the language we use to incorporate CAA, but I think the 
amount of work is not enough to justify splitting out a second working group.


___
Public mailing list
  Public@cabforum.org
  
https://cabforum.org/mailman/listinfo/public

 

___
Public mailing list
 

[cabfpub] Minutes for CA/Browser Forum Teleconference – Oct. 12, 2017

[Ben Wilson via Public]

Minutes for CA/Browser Forum Teleconference – Oct. 12, 2017



Attendees: Arno Fiedler (D-TRUST), Atsushi Inaba (GlobalSign), Ben Wilson 
(DigiCert), Christopher Kemmerer (SSL.com), Connie Enke (SwissSign), Curt Spann 
(Apple), Devon O’Brien (Google), Doug Beattie (GlobalSign), Frank Corday 
(Trustwave), Gervase Markham (Mozilla), Li-Chun Chen (Chunghwa Telecom), Mike 
Reilly (Microsoft), Neil Dunbar (Trustcor), Patrick Tronnier (OATI), Peter 
Bowen (Amazon), Peter Miscovic (Disig), Robin Alden (Comodo), Ryan Sleevi 
(Google), Shelley Brewer (DigiCert), Sissel Hoel, (Buypass), Tim Shirley 
(Trustwave), Virginia Fournier (Apple), Wayne Thayer (GoDaddy), Wendy Brown 
(Federal PKI).



1.Roll Call



2.Read Antitrust Statement



3.Review Agenda.  Agenda was approved.



4.Governance Change Working Group update. Ben said the WG had a recent 
productive call and continued to go through Gerv’s comments, and that he had 
recently circulated an updated draft of Ballot 206 to the group.  There were a 
few open issues to finish, including updating the IPR Agreement to fit the new 
structure and voting rules at the Forum level.  On voting at the Forum level, 
choices include one person-one vote with no classes, or something else (such as 
one voting group being the producers of certificates, and another voting group 
being the consumers of certificates).  There was also the question of whether a 
majority vote would be sufficient at the Forum level, or a supermajority would 
be needed.  The WG wanted input from more of the members.



Kirk suggested the WG should poll the members on choices in the undecided open 
areas.  Gerv thought a 2/3 vote by groups at the Forum level might be a good 
idea to make sure something was strongly supported, but that could be 
burdensome if a clear majority wanted something over a period of time but could 
never get to 2/3; there are pros and cons of each.  Kirk noted the Forum itself 
will only decide limited matters such as chartering of new working groups and 
some administrative matters.



Virginia believed there needed to be at least two voting groups, and favored 
producers of certificates in one group and consumers of certificates in the 
other.  Curt supported this.  Ben said the WG would need to define “consumers” 
of certificates better to go in this direction – there is now a good definition 
of what a browser is, but “consumers” could be harder to define.  The IPR 
Agreement was discussed, with Kirk saying changes were needed so that a company 
that was a Forum member but did not participate in a particular working group 
would have no obligations under the IPR Agreement.  Virginia believes the IPR 
Agreement already provides for that.



Virginia said the WG also needed to draft an initial charter for a web server 
working group, which would take over the main work of the Forum under a new 
governance structure, and that we needed to add that to the same ballot as the 
governance changes so the Forum could continue its current work.  Ben said the 
server certificate working group charter was already drafted, and agreed to 
send it out to the WG immediately.



5.Validation Working Group update.  No report.



6.Policy Review Working Group update.  Ben said the WG just had a 
productive call where it reviewed the work at the F2F meeting.  The WG is still 
refining the definition of “Certificate Authority” in the BRs, and looking at 
whether Certificate Authority could include “logical entities” as used in the 
Network Security requirements – that’s still an open issue.  Maybe a definition 
using terms such as ”function” or “service” would work better.



As a separate matter, the WG had also reviewed the proposal at the F2F by 
Chunghwa Telecom to allow certificate policy OIDS when not doing web PKI.



7.Network Security Working Group update.   Ben said the WG was looking for 
more “low hanging fruit” in the current NetSec requirements that could be 
improved by another quick ballot.  The WG also has a queue of issues of varying 
complexity that have been ranked by poll in order of importance, and was 
working through them.  At the F2F meeting, the WG had discussed again whether 
to scrap the existing NetSec requirements and rely instead on some other 
existing criteria, but had decided the answer was no because other available 
criteria were either too general or too specific for what the CA Forum members 
were doing.



Kirk asked if Ben had any idea of when the WG might be finished with its main 
issues list, and Ben guessed it might be a few months because the group only 
meets every other week.  The WG wants to do a risk analysis of CA systems 
generally in its approach, and reach agreement on what the NetSec requirements 
are really trying to protect, what the proper security perimeters for the 
standards should be, etc.



8.F2F Meeting Follow-Up: Kirk again thanked Li-Chun and Chunghwa Telecom 
for hosting an excellent and fun 

[cabfpub] Draft Charter for Server Certificate Working Group

[Ben Wilson via Public]

For everyone's review, here is a draft charter from the Governance Reform 
Committee.  This charter would be attached to Ballot 206 (Amendment to IPR 
Policy & Bylaws re Working Group Formation) and would create the Server 
Certificate Working Group under the new structure of the Forum.







Server Certificate Working Group Charter



A Server Certificate Working Group is hereby created to perform the activities 
as specified in this Charter, subject to the terms and conditions of the 
CA/Browser Forum Bylaws and applicable Intellectual Property Rights Agreement, 
as such documents may be changed from time to time.  The Definitions found in 
the Forum's Bylaws shall apply to defined terms in this Charter.



SCOPE:  The authorized scope of the Server Certificate Working Group shall be 
as follows:



1.  To specify Baseline Requirements, Extended Validation Guidelines, and 
other acceptable practices for the issuance and management of SSL/TLS server 
certificates used for authenticating servers accessible through the Internet.



2.  To update such requirements and guidelines from time to time, in order 
to address both existing and emerging threats to online security, including 
responsibility for the maintenance of and future amendments to the current 
CA/Browser Forum Baseline Requirements, Extended Validation Requirements, and 
Network and Certificate System Security Requirements.



3.  To perform such other activities that are ancillary to the primary 
activities listed above.



The Server Certificate Working Group will not address certificates intended to 
be used solely for code signing, S/MIME, time-stamping, VoIP, IM, or Web 
services.  The Server Certificate Working Group will not address the issuance, 
or management of certificates by enterprises that operate their own Public Key 
Infrastructure for internal purposes only, and for which the Root Certificate 
is not distributed by any Application Software Supplier.



Anticipated End Date:  Five (5) years from charter approval



Initial chairs and contacts:  Chair, Kirk Hall, kirk.h...@entrustdatacard.com; 
Vice Chair, Ben Wilson, ben.wil...@digicert.com; terms to run concurrently with 
their terms as Chair and Vice Chair of the Forum, unless otherwise voted upon 
by the Working Group



Members eligible to participate:  The Working Group shall consist of two 
classes of voting members, the CA Class and the Browser Class.  The CA Class 
shall consist of eligible Issuing CAs and Root CAs meeting the following 
criteria:



(1) Issuing CA: The member organization operates a certification 
authority that has a current and successful WebTrust for CAs audit, or ETSI TS 
102042, ETSI 101456, or ETSI EN 319 411-1 audit report prepared by a 
properly-qualified auditor, and that actively issues certificates to Web 
servers that are openly accessible from the Internet, such certificates being 
treated as valid when using a browser created by a Browser member.  Applicants 
that are not actively issuing certificates but otherwise meet membership 
criteria may be granted Associate Member status under Bylaw Sec. 3.1 for a 
period of time to be designated by the Forum.



(2)  Root CA: The member organization operates a certification 
authority that has a current and successful WebTrust for CAs, or ETSI TS 
102042, ETSI TS 101456, ETSI EN 319 411-1 audit report prepared by a 
properly-qualified auditor, and that actively issues certificates to 
subordinate CAs that, in turn, actively issue certificates to Web servers that 
are openly accessible from the Internet, such certificates being treated as 
valid when using a browser created by a Browser member.  Applicants that are 
not actively issuing certificates but otherwise meet membership criteria may be 
granted Associate Member status under Bylaw Sec. 3.1 for a period of time to be 
designated by the Forum.



A Non-CA member eligible to participate in the Browser Class is an organization 
that produces a software product intended for use by the general public for 
browsing the Web securely.



The Working Group shall include Interested Parties and Associate Members as 
defined in the Bylaws.



Voting structure:  In order for a ballot to be adopted by the Working Group, 
two-thirds or more of the votes cast by members in the CA Class must be in 
favor of the ballot and more than 50% of the votes cast by members in the 
Browser Class must be in favor of the ballot.  At least one member of each 
class must vote in favor of a ballot for it to be adopted.  Quorum is the 
average number of Member organizations that have participated in the previous 
three Working Group Meetings or Working Group Teleconferences.



Summary of the work that the WG plans to accomplish:  As specified above.



Summary of major WG deliverables and guidelines:  As specified above.



Primary means of communication: listserv-based email, periodic calls, and 
face-to-face meetings.



IPR Policy:  The 

Re: [cabfpub] Ballot 208 - dnQualifiers

[Ben Wilson via Public]

DigiCert votes "yes"  on Ballot 208

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ben Wilson
via Public
Sent: Thursday, October 12, 2017 12:05 PM
To: CABFPub <public@cabforum.org>
Subject: [cabfpub] Ballot 208 - dnQualifiers

 

Ballot 208 - dnQualifiers 

This ballot allows CAs to use dnQualifiers in certificates to partition
groups of certificates into different sets and to allow non-identity
information to be included in DV certificates. 

The following motion has been proposed by Peter Bowen of Amazon and endorsed
by Ben Wilson of DigiCert and Ryan Sleevi of Google. 

-- MOTION BEGINS -- 

In the Baseline Requirements, REPLACE the definition of "Subject Identity
Information" with: 

"Information that identifies the Certificate Subject. Subject Identity
Information does not include [strikeout]a domain name listed in the
subjectAltName extension or the Subject commonName field[/strikeout]
[insert]dnQualifier attributes in Distinguished Names, commonName attributes
in Distinguished Names, dNSName Subject Alternative Names, iPAddress Subject
Alternative Names, or SRVName Subject Alternative Names[/insert]." 

In Section 7.1.4.2.2 Subject Distinguished Name Fields, re-letter "j" (Other
Subject Attributes) as letter "k" and INSERT a new subsection j. that reads:


j. Certificate Field: subject:dnQualifier 

*   Optional. Contents: This field is intended to be used when several
certificates with the same subject can be partitioned into sets of related
certificates. Each related certificate set MAY have the same dnQualifier.
The CA may include a dnQualifier attribute with a zero length value to
explicitly indicate that the CA makes no assertion about relationship with
other certificates with the same subject. The CA MAY set the dnQualifer
value to the base64 encoding of the SHA1 hash of the subjectAlternativeName
extnValue if it wishes to indicate grouping of certificates by alternative
name set. 

-- MOTION ENDS -- 

The procedure for approval of this Final Maintenance Guideline ballot is as
follows (exact start and end times may be adjusted to comply with applicable
Bylaws and IPR Agreement): 

BALLOT 208 Status: Final Maintenance Guideline Start time (22:00 UTC) End
time (22:00 UTC) 

Discussion begins October 12, 2017 22:00 UTC and ends October 19, 2017 22:00
UTC (7 days) 

Vote for approval begins October 19, 2017 22:00 UTC and ends October 26,
2017 22:00 UTC (7 days) 

If vote approves ballot: Review Period (Chair to send Review Notice) (30
days). If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to
be created. If no Exclusion Notices filed, ballot becomes effective at end
of Review Period. Upon filing of Review Notice by Chair 30 days after filing
of Review Notice by Chair 

>From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final
Maintenance Guideline, such ballot will include a redline or comparison
showing the set of changes from the Final Guideline section(s) intended to
become a Final Maintenance Guideline, and need not include a copy of the
full set of guidelines. Such redline or comparison shall be made against the
Final Guideline section(s) as they exist at the time a ballot is proposed,
and need not take into consideration other ballots that may be proposed
subsequently, except as provided in Bylaw Section 2.3(j). 

Votes must be cast by posting an on-list reply to this thread on the Public
list. A vote in favor of the motion must indicate a clear 'yes' in the
response. A vote against must indicate a clear 'no' in the response. A vote
to abstain must indicate a clear 'abstain' in the response. Unclear
responses will not be counted. The latest vote received from any
representative of a voting member before the close of the voting period will
be counted. Voting members are listed here: https://cabforum.org/members/ 

In order for the motion to be adopted, two thirds or more of the votes cast
by members in the CA category and greater than 50% of the votes cast by
members in the browser category must be in favor. Quorum is shown on
CA/Browser Forum wiki. Under Bylaw 2.2(g), at least the required quorum
number must participate in the ballot for the ballot to be valid, either by
voting in favor, voting against, or abstaining. 

 



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

Re: [cabfpub] Pre-Ballot 209 EV Liability

[Ben Wilson via Public]

Moudrick and others,

 

Is the following proposed change to section 18 of the EV Guidelines more clear?


18.  Liability and Indemnification


CAs MAY limit their liability as described in Section 9.8 of the Baseline 
Requirements except that a CA MAY NOT limit its liability to Subscribers or 
Relying Parties for legally recognized and provable claims to a monetary amount 
less than one or any combination of the following: 

(1)two thousand US dollars ($2,000) - per Subscriber or Relying Party per 
EV Certificate;

(2)one hundred thousand US dollars ($100,000) – aggregated across all 
claims, Subscribers, and Relying Parties – per EV Certificate; or

(3)five million US dollars ($5,000,000) – aggregated across all claims, 
Subscribers, and Relying Parties – for all EV Certificates issued by the CA 
during any continuous 12-month period. 

 

Thanks,

 

Ben

 

From: Moudrick M. Dadashov [mailto:m...@ssc.lt] 
Sent: Wednesday, July 26, 2017 2:32 PM
To: Ben Wilson <ben.wil...@digicert.com>; CA/Browser Forum Public Discussion 
List <public@cabforum.org>
Subject: Re: [cabfpub] Pre-Ballot 209 EV Liability

 

Thanks, Ben.

Assuming that any combination (of 1,2, 3) or no combination at all would be 
acceptable, could we add something like "at least one or any combination of 
following" so that it is explicitly clear?

Thanks,
M.D.

CAs MAY limit their liability as described in Section 9.8 of the Baseline 
Requirements except that a CA MAY NOT limit its liability to Subscribers or 
Relying Parties for legally recognized and provable claims to a monetary amount 
less than:  



On 7/26/2017 5:12 AM, Ben Wilson wrote:

Rather than tack on these two additional limits, what if it were simplified to 
read:

 

CAs MAY limit their liability as described in Section 9.8 of the Baseline 
Requirements except that a CA MAY NOT limit its liability to Subscribers or 
Relying Parties for legally recognized and provable claims to a monetary amount 
less than: 

 (1)  two thousand US dollars per Subscriber or Relying Party 
per EV Certificate;

 (2)  one hundred thousand US dollars – aggregated across all 
claims, Subscribers, and Relying Parties – per EV Certificate; and/or

 (3)  five million US dollars – aggregated across all claims, 
Subscribers, and Relying Parties – for all EV Certificates issued by the CA 
during any continuous 12-month period. 

 

These limitations are notwithstanding anything in the Baseline Requirements 
purportedly to the contrary.

 

A CA's indemnification obligations and a Root CA’s obligations with respect to 
subordinate CAs are set forth in Section 9.9 of the Baseline Requirements.

 

 

 

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ben Wilson via 
Public
Sent: Tuesday, July 25, 2017 6:37 PM
To: Moudrick M. Dadashov  <mailto:m...@ssc.lt> <m...@ssc.lt>; CA/Browser Forum 
Public Discussion List  <mailto:public@cabforum.org> <public@cabforum.org>
Subject: Re: [cabfpub] Pre-Ballot 209 EV Liability

 

Would this work?

 

Notwithstanding the foregoing, a CA MAY limit its liability to Subscribers or 
Relying Parties for legally recognized and provable claims to not less than: 
(1) one hundred thousand US dollars – aggregated across all claims, 
Subscribers, and Relying Parties – per EV Certificate; and/or (2) five million 
US dollars – aggregated across all claims, Subscribers, and Relying Parties – 
for all EV Certificates issued by the CA during any continuous 12-month period. 
These limitations are notwithstanding anything in the Baseline Requirements 
purportedly to the contrary.

 

From: Moudrick M. Dadashov [mailto:m...@ssc.lt] 
Sent: Tuesday, July 25, 2017 5:48 PM
To: Ben Wilson <ben.wil...@digicert.com <mailto:ben.wil...@digicert.com> >; 
CA/Browser Forum Public Discussion List <public@cabforum.org 
<mailto:public@cabforum.org> >
Subject: Re: [cabfpub] Pre-Ballot 209 EV Liability

 

Would you mind to show how it would sound now? :)

Thanks,
M.D.

On 7/26/2017 2:14 AM, Ben Wilson wrote:

And it should be an “and” or a “but”, but rephrased nevertheless.

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 

From: Ben Wilson 
Sent: Tuesday, July 25, 2017 5:11 PM
To: Ben Wilson  <mailto:ben.wil...@digicert.com> <ben.wil...@digicert.com>; 
CA/Browser Forum Public Discussion List  <mailto:public@cabforum.org> 
<public@cabforum.org>; Moudrick M. Dadashov  <mailto:m...@ssc.lt> <m...@ssc.lt>
Subject: RE: [cabfpub] Pre-Ballot 209 EV Liability

 

Never mind – I think I now see your point.  Not “up to” it needs to be “not 
less than $5 million.”  Would that make it clearer?

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ben Wilson via 
Public
Sent: Tuesday, July 25, 2017 5:10 PM
To: Moudrick M. Dadashov <m..

Re: [cabfpub] BRs, EVGLs, and "latest version"

[Ben Wilson via Public]

Ryan,

One issue with the qualified audit,  as was expressed during the face-to-face 
meeting, although I haven’t been able to  find it, is that Microsoft apparently 
requires the WebTrust seal, which is based on an unqualified audit.  If anyone 
can point me to the  requirement, I’d appreciate it.

Thanks,

Ben

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Monday, October 9, 2017 6:40 AM
To: Gervase Markham ; CA/Browser Forum Public Discussion List 

Subject: Re: [cabfpub] BRs, EVGLs, and "latest version"

 

 

 

On Fri, Oct 6, 2017 at 12:07 PM, Gervase Markham via Public 
 > wrote:

During the CAB Forum face-to-face in Taipei, it was noted that the BRs
currently state something which implies something which is not true in
practice.

 

Gerv,

 

I think it's useful here to distinguish between things which are expected and 
things which are audited. As has been discussed in the Forum for years, the 
audit criteria naturally lag behind the adoption of the BRs - depending on when 
a ballot is adopted, this can be as short as a few months, or as long as a few 
years.

 

I can think of a number of problems your proposed language would introduce, and 
on that basis, would have difficulty supporting, so it might be useful if you 
could articulate the problem you are trying to solve.

 

For example, it seems you might be trying to solve what you view as "the CAA 
problem". However, I think it's worth noting that the CAA problem was 
self-inflicted - the Forum had been discussing CAA since 2012, had specifically 
been concerned about potential gotchas and thus introduced the simple mandate 
to require disclosing CAA practices (allowing CAs to gain experience with CAA 
without any risk of BR violations, by virtue of allowing CP/CPS flexibility), 
and then put a CAA requirement 6 months in advance of the actual deadline. The 
issues only manifest because a "deadline" was taken as an "implementation date" 
- that is, all of the flexibility was rejected and deprioritized by CAs, and 
they waited until the last minute.

 

However, it also seems to be operating on a misguided - and I would argue 
dangerous to the ecosystem - belief that qualified audits represent a fatal 
state. We know, through similar lengthy discussions in the Forum on the nature 
of audits, that not every failure necessarily represents a qualification (as it 
relies on the auditor's opinion as well as the nature of the principles and 
criteria), but we also know that disclosure through audit is far better for the 
ecosystem than relentlessly chasing a 'clean' audit. Indeed, Mozilla's own 
efforts have been to underscore that point - that a qualified audit is not 
fatal - so I admit, it seems somewhat surprising to see you suggest undermining 
both security and the quality of audits in pursuit of unqualified audits.

 

Could you elaborate on whether there are goals or context that I have missed - 
and the relative value of those goals compared to the ecosystem value? In doing 
so, I'd be happy to elaborate how your proposal would result in less security 
and less transparency, and the ways in which it could be gamed or 
unintentionally overlooked, in a way that would be detrimental to the ecosystem.


Best,

Ryan



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

Re: [cabfpub] BRs, EVGLs, and "latest version"

[Ben Wilson via Public]

Would all of the browsers need to adopt some type of statement to the effect
that "all CAs are expected to comply with the most recent version of the
Baseline Requirements and EV Guidelines?  It seems you are just moving the
statement/requirement from one place to another?


-Original Message-
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase
Markham via Public
Sent: Friday, October 6, 2017 10:08 AM
To: CABFPub 
Subject: [cabfpub] BRs, EVGLs, and "latest version"

During the CAB Forum face-to-face in Taipei, it was noted that the BRs
currently state something which implies something which is not true in
practice.

In section 2, they say:

"The CA SHALL develop, implement, enforce, and annually update a Certificate
Policy and/or Certification Practice Statement that describes in detail how
the CA implements the latest version of these Requirements."

There are similar statements in sections 2.2 and 2.3 (not sure why it needed
to be said 3 times). And there's one for EV in section 8.3 of the EVGLs. So,
according to the documents, when you say you are conforming to a particular
version, you should actually be conforming to the latest version.

The problem is that this is not how audits work. When a CA is given a BR
audit, they are not audited to the latest version. They are audited to the
version which has been translated into audit criteria in whatever version of
the criteria are in use - e.g. for WebTrust for BRs 2.2 (the current
version), that would be BRs 1.4.2[0]. The auditors present confirmed that
they do not, in fact, audit to the latest version, as the documents suggest
they do. This lag (some months, these days) could be considered a feature,
not a bug; it allows us to "debug" bits of the BRs before they get fixed
into audit criteria.

It is undoubtedly, from my perspective, a good thing that CAs are required
to conform to the latest version of the BRs and EVGLs. That's why Mozilla
Policy 2.5 says in section 2.3:

"CA operations relating to issuance of certificates capable of being used
for SSL-enabled servers MUST also conform to the latest version of the
CA/Browser Forum Baseline Requirements for the Issuance and Management of
Publicly-Trusted Certificates ("Baseline Requirements")."

There's a similar statement for EV in Mozilla Policy 2.5 section 2.2.4.

Therefore, removing the "latest version" statements from the BRs and EVGLs
would not change the obligations on CAs to actually conform to the latest
version, but would make it much more clear where that obligation comes from
(root program requirements) and make it much more clear what auditors do
(audit to the version of the BRs they have encoded in their audit criteria).
It means that if/when root programs give a BR dispensation for something in
the BRs of a version later than the audited version, there is no risk at all
that anyone will be concerned that the discrepancy will nevertheless show up
in their audit.

So my suggestion is that we pass a motion removing that language.

Any objections?

Gerv

[0] http://www.webtrust.org/principles-and-criteria/docs/item83987.pdf
___
Public mailing list
Public@cabforum.org
https://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] [EXTERNAL]Missing Failed Ballots results on webpage

[Ben Wilson via Public]

Ryan and Kirk,

 

I’ve posted the three failed ballots to the CA/Browser Forum website now.

 

  
https://cabforum.org/2017/02/24/ballot-185-limiting-lifetime-certificates/ 

 

 

 
https://cabforum.org/2017/03/02/ballot-188-clarify-use-term-ca-baseline-requirements/
 

 

  
https://cabforum.org/2017/07/26/ballot-202-underscore-wildcard-characters/  

 

Please let me know if you find any other missing information that you’d like to 
see on the website. 

 

Ben

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Tuesday, October 3, 2017 8:19 PM
To: Kirk Hall 
Cc: CABFPub 
Subject: Re: [cabfpub] [EXTERNAL]Missing Failed Ballots results on webpage

 

Hi Kirk,

 

We already have a Webmaster. Wayne :)

 

On Tue, Oct 3, 2017 at 4:39 PM, Kirk Hall  > wrote:

Actually, the Chair gets to appoint a Webmaster – will you be willing to take 
that on?

 

The Chair shall appoint a Webmaster. The Webmaster shall post instructions on 
the Public

Web Site for subscribing to the Public Mail List.

The following materials shall be posted to the Public Mail List or Public Web 
Site: ***

 

From: Ryan Sleevi [mailto:sle...@google.com  ] 
Sent: Wednesday, October 4, 2017 7:03 AM
To: Kirk Hall  >
Cc: CABFPub  >
Subject: Re: [EXTERNAL]Missing Failed Ballots results on webpage

 

Our rules don't require such to the Wiki. In fact, nothing is required to use 
the wiki.

 

The responsibility for these activities fall to the Chair and the Webmaster per 
5.2 of our Bylaws.

 

On Tue, Oct 3, 2017 at 4:00 PM, Kirk Hall  > wrote:

I’m not sure who has been maintaining that page – we can discuss at our meeting 
today.  I also notice that the basic ballot text and  results on our wiki are 
missing for several ballots going way back.  I believe our rules should require 
the proposers and endorsers of a ballot post it to the wiki at the beginning of 
the discussion period (and later posts all amendments), and not just rely on 
email updates – I’ll proposed that to the group today.

 

From: Ryan Sleevi [mailto:sle...@google.com  ] 
Sent: Tuesday, October 3, 2017 11:58 AM
To: Kirk Hall  >
Cc: CABFPub  >
Subject: [EXTERNAL]Missing Failed Ballots results on webpage

 

Kirk,

 

When looking through https://cabforum.org/category/proceedings/ballots/ , I 
happened to notice the following ballots were missing:

 

Ballot 185 - Limiting the Lifetime of Certificates

  - https://cabforum.org/pipermail/public/2017-February/009639.html

 

Ballot 188 - Clarify use of term “CA” in Baseline Requirements

  - https://cabforum.org/pipermail/public/2017-February/009653.html

 

Ballot 202 - Underscore Characters in SANs

  - https://cabforum.org/pipermail/public/2017-July/011582.html

 

These were three that formally went to the voting process and failed, which is 
why I suspect they were omitted. Could you make sure the ballots and their 
tallies are also part of the minutes.

 

I looked through 
https://docs.google.com/spreadsheets/d/1FBsMZjlzyvK3mFR1u4qMqvZwlI86yJ-v0am1pCBo8uI/edit?pref=2
 

 =1#gid=1202563089 and it looks like it was just those three that made it 
to voting but failed since the transition from Dean.

 

Ballot 194 was rescinded (reappeared as 197)

Ballot 186 didn't advance to voting

Ballot 184 didn't advance to voting

Ballot 182 didn't advance to voting

 

 

 



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

[cabfpub] Ballot 190 and BR v. 1.5.2

[Ben Wilson via Public]

With passage of Ballot 190, I have created a new version 1.5.2 of the
Baseline Requirements, which I'll post shortly to the Forum website.
However, we've noticed in creating this version 1.5.2 that Ballot 190 was
drafted before passage of Ballot 204, which removed "or Delegated Third
Party" from section 3.2.2.4.  Ballot 190 inadvertently added "or Delegated
Third Party" back into the Baseline Requirements.  So Rich Smith, Tim
Hollebeek and I are going to propose an errata ballot to re-remove "or
Delegated Third Party" from section 3.2.2.4, unless everyone thinks that the
intent of Ballot 204 should supersede the contradictory language in Ballot
190.

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 



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

Re: [cabfpub] Voting has started on Ballot 190

[Ben Wilson via Public]

DigiCert votes “yes”

 

From: Public  
> on behalf of Kirk Hall via Public  >
Reply-To: Kirk Hall  >, CA/Browser Forum Public Discussion 
List  >
Date: Tuesday, September 12, 2017 at 3:23 PM
To: CA/Browser Forum Public Discussion List  >
Subject: [cabfpub] Voting has started on Ballot 190

 

Voting has started on Ballot 190 as proposed on Sept 5 (see bottom of this 
message, and attachments), as amended by my email from Sept. 11 (see 
immediately below).  Voting runs through Sept. 19 at 18:00 UTC.

 

Entrust votes yes.

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Kirk Hall via 
Public
Sent: Monday, September 11, 2017 6:01 AM
To: CA/Browser Forum Public Discussion List  >
Subject: [EXTERNAL][cabfpub] Two amendments to Ballot 190

 

The proposer and endorsers are making two minor amendments to Ballot 190 as 
follows.

 

1) In BR 3.2.2.4.6 "Agreed-Upon Change to Website", the current draft Version 8 
still has the typo "Request Value" that crept in sometime around BR 1.4. It 
should be "Random Value".  Accordingly, BR 3.2.2.4.6 in Ballot 190 is changed 
to read as follows:

 

3.2.2.4.6 Agreed-Upon Change to Website

 

Confirming the Applicant's control over the FQDN by confirming one of the 
following under the "/.well-known/pki-validation" directory, or another path 
registered with IANA for the purpose of Domain Validation, on the Authorization 
Domain Name that is accessible by the CA via HTTP/HTTPS over an Authorized Port:

 

1.   The presence of Required Website Content contained in the content of a 
file. The entire Required Website Content MUST NOT appear in the request used 
to retrieve the file or web page, or

 

2.   The presence of the Request Token or Request Random Value contained in 
the content of a file where the Request Token or Random Value MUST NOT appear 
in the request. ***

 

2) In Version 8 of BR 3.2.2.4.7, "DNS Change", the current language says:

 

"Confirming the Applicant's control over the FQDN by confirming the presence of 
a Random Value or Request Token for either in a DNS CNAME, TXT or CAA record 
for either 1) an Authorization Domain Name; or 2) an Authorization Domain Name 
that is prefixed with a label that begins with an underscore character."  

 

Note that "for either" appears twice in the sentence, and we think the first 
occurrence should be deleted.  Accordingly, BR 3.2.2.4.7 in Ballot 190 is 
changed to read as follows:

 

3.2.2.4.7  DNS Change

Confirming the Applicant's control over the FQDN by confirming the presence of 
a Random Value or Request Token for either in a DNS CNAME, TXT or CAA record 
for either 1) an Authorization Domain Name; or 2) an Authorization Domain Name 
that is prefixed with a label that begins with an underscore character.

 

Voting on Ballot 190 will begin tomorrow, and the text has been changed as 
shown above.

***

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Kirk Hall via 
Public
Sent: Tuesday, September 5, 2017 10:52 AM
To: CA/Browser Forum Public Discussion List  >
Subject: [EXTERNAL][cabfpub] Ballot 190 - Discussion Period is starting

 

As agreed on our CABF teleconference last week, we are starting the formal 
discussion period for Ballot 190 (in this case, v8).  I have attached the 
ballot in two formats and in three modes.

 

The title of the actual ballot to be voted on uses all capital letters “BALLOT 
190 v8 (9-5-2017)”.  I also attach a version that includes some explanatory 
comments, and a “clean” version showing how the BRs will read if Ballot 190 v8 
is adopted “Ballot 190 v8 (9-5-2017) (showing BRs if adopted)”.

 

The discussion period ends Sept. 12 at 18:00 UTC, and the voting period runs 
Sept. 12-19.

 

This version 8 is based on the prior version 7, but includes a limited number 
of changes as outlined in emails among me, Ryan, and Doug on Aug. 29-30.  

 

We are almost there!  Thanks to everyone who has worked on this effort over the 
past two years.  Assuming Ballot 190 passes, the Validation Working Group can 
then start work on further amendments as outlined in my prior emails.

 



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

[cabfpub] Ballots 210 and 212

[Ben Wilson via Public]

The documents amended by Ballots 210 and 212 (the Network and Certificate
System Security Requirements and the Baseline Requirements, respectively),
have been updated on GitHub and are live now on the CA/Browser Forum
website.  I'll upload the Word versions of the files up to  the wiki
shortly.

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 



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

Re: [cabfpub] Ballot 212: Canonicalise formal name of the Baseline Requirements

[Ben Wilson via Public]

DigiCert votes “yes”

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase Markham 
via Public
Sent: Friday, August 18, 2017 9:06 AM
To: CABFPub 
Subject: [cabfpub] Ballot 212: Canonicalise formal name of the Baseline 
Requirements

 

Ballot 212: Canonicalise formal name of the Baseline Requirements 

Purpose of Ballot: to make the formal name of the Baseline Requirements 
document clear, as use is not currently consistent.

The following motion has been proposed by Gervase Markham of Mozilla and 
endorsed by Jeremy Rowley of DigiCert and Ryan Sleevi of Google: 

-- MOTION BEGINS -- 

The official name of the Baseline Requirements document shall be 'The Baseline 
Requirements for the Issuance and Management of Publicly-Trusted Certificates'. 
Approved abbreviations for official use are "the Baseline Requirements", and 
"the BRs".

Editors and maintainers of CAB Forum documents and websites are empowered to 
update text under their control at any time to make this so.

-- MOTION ENDS -- 

The procedure for approval of this ballot is as follows: 


Start time (22:00 UTC) 

End time (22:00 UTC) 


Discussion (7 to 14 days) 

18 Aug

25 Aug


Vote for approval (7 days) 

25 Aug

1 Sep



Votes must be cast by posting an on-list reply to this thread on the Public 
list. A vote in favor of the motion must indicate a clear 'yes' in the 
response. A vote against must indicate a clear 'no' in the response. A vote to 
abstain must indicate a clear 'abstain' in the response. Unclear responses will 
not be counted. The latest vote received from any representative of a voting 
member before the close of the voting period will be counted. Voting members 
are listed here: https://cabforum.org/members/ 

In order for the motion to be adopted, two thirds or more of the votes cast by 
members in the CA category and greater than 50% of the votes cast by members in 
the browser category must be in favor. Quorum is shown on CA/Browser Forum 
wiki. Under Bylaw 2.2(g), at least the required quorum number must participate 
in the ballot for the ballot to be valid, either by voting in favor, voting 
against, or abstaining. 



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

Re: [cabfpub] Voting has started on Ballot 210 (NetSec Revisions)

[Ben Wilson via Public]

DigiCert votes "yes"



From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Kirk Hall via 
Public
Sent: Friday, August 25, 2017 9:47 AM
To: CA/Browser Forum Public Discussion List <public@cabforum.org>
Subject: [cabfpub] Voting has started on Ballot 210 (NetSec Revisions)



Entrust votes yes



From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ben Wilson via 
Public
Sent: Saturday, August 12, 2017 8:30 PM
To: CABFPub <public@cabforum.org<mailto:public@cabforum.org>>
Subject: cabfpub] Ballot 210: Misc. Changes to the Network and Certificate 
System Security Requirements



The discussion period for this ballot is 12 days to give everyone ample time to 
review it.  Voting will start at 2200 UTC on Thursday, August 24, 2017.

The Network Security Working Group recommends that the Forum make the following 
minor revisions to the Network and Certificate System Security Requirements.   
(Other changes are being considered by the Working Group and will be presented 
in due course.)

The following ballot is proposed by Dimitris Zacharopoulos of HARICA and 
endorsed by Ben Wilson of DigiCert and Neil Dunbar of TrustCor.

--Motion Begins--

In the Network and Certificate System Security Requirements:

ADD ETSI EN 319 411-1 to first sentence of the Scope and Applicability section 
so that it reads "These Network and Certificate System Security Requirements 
(Requirements) apply to all publicly trusted Certification Authorities (CAs) 
and are adopted with the intent that all such CAs and Delegated Third Parties 
be audited for conformity with these Requirements as soon as they have been 
incorporated as mandatory requirements (if not already mandatory requirements) 
in the root embedding program for any major Internet browsing client and that 
they be incorporated into the WebTrust Service Principles and Criteria for 
Certification Authorities, ETSI TS 101 456, ETSI TS 102 042 and ETSI EN 319 
411-1 including revisions and implementations thereof, including any audit 
scheme that purports to determine conformity therewith."

REPLACE section 1.a. with "a. Segment Certificate Systems into networks based 
on their functional or logical relationship, for example separate physical 
networks or VLANs;"

REPLACE section 1.b. with "b. Apply equivalent security controls to all systems 
co-located in the same network with a Certificate System;"

REPLACE "90 days" with "three (3) months" in section 2.g.ii. and 2.j so that 
they read "ii. For accounts that are accessible from outside a Secure Zone or 
High Security Zone, require that passwords have at least eight (8) characters, 
be changed at least every three (3) months, use a combination of at least 
numeric and alphabetic characters, that are not a dictionary word or on a list 
of previously disclosed human-generated passwords, and not be one of the user's 
previous four (4) passwords; and implement account lockout for failed access 
attempts in accordance with subsection k; OR"

AND

"j. Review all system accounts at least every three (3) months and deactivate 
any accounts that are no longer necessary for operations;"

REPLACE section 2.m. with "m. Enforce multi-factor OR multi-party 
authentication for administrator access to Issuing Systems and Certificate 
Management Systems;"

REPLACE section 2.o. with "o. Restrict remote administration or access to an 
Issuing System, Certificate Management System, or Security Support System 
except when: (i) the remote connection originates from a device owned or 
controlled by the CA or Delegated Third Party, (ii) the remote connection is 
through a temporary, non-persistent encrypted channel that is supported by 
multi-factor authentication, and (iii) the remote connection is made to a 
designated intermediary device (a) located within the CA's network, (b) secured 
in accordance with these Requirements, and (c) that mediates the remote 
connection to the Issuing System."

REPLACE "every 30 days and" with "once a month to" in section 3.e. so that it 
reads "e. Conduct a human review of application and system logs at least once a 
month to validate the integrity of logging processes and ensure that 
monitoring, logging, alerting, and log-integrity-verification functions are 
operating properly (the CA or Delegated Third Party MAY use an in-house or 
third-party audit log reduction and analysis tool); and"

REPLACE 4.a. with "a. Implement intrusion detection and prevention controls 
under the control of CA or Delegated Third Party Trusted Roles to protect 
Certificate Systems against common network and system threats;"

REPLACE 4.C. with "c. Undergo or perform a Vulnerability Scan (i) within one 
(1) week of receiving a request from the CA/Browser Forum, (ii) after any 
system or network changes that the CA determines are significant, and (iii) at 

Re: [cabfpub] Random value reuse

[Ben Wilson via Public]

Right.  The definition should be rewritten without the "applicant" included.

-Original Message-
From: Peter Bowen [mailto:p...@amzn.com] 
Sent: Wednesday, August 9, 2017 3:49 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: Ben Wilson <ben.wil...@digicert.com>; geo...@apple.com; CA/Browser Forum 
Public Discussion List <public@cabforum.org>; Gervase Markham 
<g...@mozilla.org>; Rich Smith <richard.sm...@comodo.com>
Subject: Re: [cabfpub] Random value reuse

In methods 2 & 4 it goes to the domain contact or a role account at the domain. 
 Giving it to the applicant voids the whole purpose of the exercise, as the 
applicant isn’t the one who needs to approve the request.

Thanks,
Peter

> On Aug 9, 2017, at 2:46 PM, Jeremy Rowley <jeremy.row...@digicert.com> wrote:
> 
> How do you figure? They can provide it by email to the applicant.  
> 
> -Original Message-
> From: Peter Bowen [mailto:p...@amzn.com]
> Sent: Wednesday, August 9, 2017 3:46 PM
> To: Ben Wilson <ben.wil...@digicert.com>
> Cc: geo...@apple.com; CA/Browser Forum Public Discussion List 
> <public@cabforum.org>; Gervase Markham <g...@mozilla.org>; Jeremy 
> Rowley <jeremy.row...@digicert.com>; Rich Smith 
> <richard.sm...@comodo.com>
> Subject: Re: [cabfpub] Random value reuse
> 
> That definition is problematic.  In methods 2 & 4, the CA doesn’t provide the 
> random value to the applicant.
> 
>> On Aug 9, 2017, at 2:33 PM, Ben Wilson <ben.wil...@digicert.com> wrote:
>> 
>> I suppose you're right, since the definition of "Random Value" is "A value 
>> specified by a CA to the Applicant that exhibits at least 112 bits of 
>> entropy."
>> 
>> 
>> -Original Message-
>> From: geo...@apple.com [mailto:geo...@apple.com]
>> Sent: Wednesday, August 9, 2017 3:30 PM
>> To: Ben Wilson <ben.wil...@digicert.com>
>> Cc: CA/Browser Forum Public Discussion List <public@cabforum.org>; 
>> Gervase Markham <g...@mozilla.org>; Jeremy Rowley 
>> <jeremy.row...@digicert.com>; Rich Smith <richard.sm...@comodo.com>; 
>> Peter Bowen <p...@amzn.com>
>> Subject: Re: [cabfpub] Random value reuse
>> 
>> 
>>> On 9 Aug 2017, at 2:24 pm, Ben Wilson <ben.wil...@digicert.com> wrote:
>>> 
>>> Agreed.  And each method should stand on its own without cross-referencing 
>>> among methods (otherwise tracking the particular method used will be too 
>>> complicated).  So I'm OK without cross-referencing methods.
>>> 
>>> But are we clear enough?  For example, the currently proposed method 10 
>>> could probably benefit from better language on how the applicant obtains 
>>> the random value.  Currently it only says, "Confirming the Applicant's 
>>> control over the FQDN by confirming the presence of a Random Value within a 
>>> Certificate on the Authorization Domain Name which is accessible by the CA 
>>> via TLS over an Authorized Port."  The other methods seem to specify the 
>>> process more thoroughly.
>> 
>> I think it doesn’t matter, in this case, how the Random Value gets to the 
>> Applicant—we don’t want to overspecify things like this, because that limits 
>> the ability of CAs to innovate.
>> 
>>> 
>>> -Original Message-
>>> From: geo...@apple.com [mailto:geo...@apple.com]
>>> Sent: Wednesday, August 9, 2017 3:11 PM
>>> To: Ben Wilson <ben.wil...@digicert.com>; CA/Browser Forum Public 
>>> Discussion List <public@cabforum.org>
>>> Cc: Gervase Markham <g...@mozilla.org>; Jeremy Rowley 
>>> <jeremy.row...@digicert.com>; Rich Smith <richard.sm...@comodo.com>; 
>>> Peter Bowen <p...@amzn.com>
>>> Subject: Re: [cabfpub] Random value reuse
>>> 
>>> I think that’s where the ‘single communication’ rule really helps.  
>>> Then this is taken care of by the descriptions of the methods: if 
>>> you have to send the random value to a particular place, then 
>>> obviously that can’t be combined with a random value sent some other 
>>> way; if you have to put it in a particular place, then it doesn’t 
>>> matter how it was sent…
>>> 
>>>> On 9 Aug 2017, at 1:54 pm, Ben Wilson via Public <public@cabforum.org> 
>>>> wrote:
>>>> 
>>>> Putting the  issue of "reuse" aside, do we need to clarify this issue of 
>>>> which random value methods can be used in combination with others?  It 
>>>> seems that a random value

Re: [cabfpub] Random value reuse

[Ben Wilson via Public]

Agreed.  And each method should stand on its own without cross-referencing 
among methods (otherwise tracking the particular method used will be too 
complicated).  So I'm OK without cross-referencing methods.

 But are we clear enough?  For example, the currently proposed method 10 could 
probably benefit from better language on how the applicant obtains the random 
value.  Currently it only says, "Confirming the Applicant's control over the 
FQDN by confirming the presence of a Random Value within a Certificate on the 
Authorization Domain Name which is accessible by the CA via TLS over an 
Authorized Port."  The other methods seem to specify the process more 
thoroughly.


-Original Message-
From: geo...@apple.com [mailto:geo...@apple.com] 
Sent: Wednesday, August 9, 2017 3:11 PM
To: Ben Wilson <ben.wil...@digicert.com>; CA/Browser Forum Public Discussion 
List <public@cabforum.org>
Cc: Gervase Markham <g...@mozilla.org>; Jeremy Rowley 
<jeremy.row...@digicert.com>; Rich Smith <richard.sm...@comodo.com>; Peter 
Bowen <p...@amzn.com>
Subject: Re: [cabfpub] Random value reuse

I think that’s where the ‘single communication’ rule really helps.  Then this 
is taken care of by the descriptions of the methods: if you have to send the 
random value to a particular place, then obviously that can’t be combined with 
a random value sent some other way; if you have to put it in a particular 
place, then it doesn’t matter how it was sent…

> On 9 Aug 2017, at 1:54 pm, Ben Wilson via Public <public@cabforum.org> wrote:
> 
> Putting the  issue of "reuse" aside, do we need to clarify this issue of 
> which random value methods can be used in combination with others?  It seems 
> that a random value could be provided to the domain contact / admin under 
> methods 2, 3 (if you wanted) or 4 and then used within 30 days for methods 2, 
> 4, 6, 7 and 10,  but not vice versa.
> 
> -Original Message-
> From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase 
> Markham via Public
> Sent: Monday, July 31, 2017 9:02 AM
> To: Jeremy Rowley <jeremy.row...@digicert.com>; CA/Browser Forum Public 
> Discussion List <public@cabforum.org>; Rich Smith <richard.sm...@comodo.com>; 
> 'Peter Bowen' <p...@amzn.com>
> Subject: Re: [cabfpub] Random value reuse
> 
> On 28/07/17 14:53, Jeremy Rowley via Public wrote:
>> I think the random value should be tied to a single communication 
>> without reuse.  For example, a single email sent to the constructed 
>> emails, a single API call, a single phone call, etc.  The random value 
>> shouldn’t be tied to a method, but should be tied to a specific 
>> communication from the CA that is tied to a request. By getting rid of 
>> the reuse language, we can simplify the process and eliminate the risk 
>> associated with reuse.
> 
> Right. New random values are cheap :-)
> 
> Gerv
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
> ___
> Public mailing list
> Public@cabforum.org
> https://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] Random value reuse

[Ben Wilson via Public]

Putting the  issue of "reuse" aside, do we need to clarify this issue of which 
random value methods can be used in combination with others?  It seems that a 
random value could be provided to the domain contact / admin under methods 2, 3 
(if you wanted) or 4 and then used within 30 days for methods 2, 4, 6, 7 and 
10,  but not vice versa.

-Original Message-
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase Markham 
via Public
Sent: Monday, July 31, 2017 9:02 AM
To: Jeremy Rowley ; CA/Browser Forum Public 
Discussion List ; Rich Smith ; 
'Peter Bowen' 
Subject: Re: [cabfpub] Random value reuse

On 28/07/17 14:53, Jeremy Rowley via Public wrote:
> I think the random value should be tied to a single communication 
> without reuse.  For example, a single email sent to the constructed 
> emails, a single API call, a single phone call, etc.  The random value 
> shouldn’t be tied to a method, but should be tied to a specific 
> communication from the CA that is tied to a request. By getting rid of 
> the reuse language, we can simplify the process and eliminate the risk 
> associated with reuse.

Right. New random values are cheap :-)

Gerv
___
Public mailing list
Public@cabforum.org
https://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] [EXTERNAL]Re: Ballot 190 - Recording BR Version Number

[Ben Wilson via Public]

Wayne,
Can you give an example of what embedding would look like?
Thanks,
Ben

From: Wayne Thayer<mailto:wtha...@godaddy.com>
Sent: ‎8/‎1/‎2017 3:58 PM
To: Ben Wilson<mailto:ben.wil...@digicert.com>; CA/Browser Forum Public 
Discussion List<mailto:public@cabforum.org>; Gervase 
Markham<mailto:g...@mozilla.org>; Kirk 
Hall<mailto:kirk.h...@entrustdatacard.com>
Subject: Re: [cabfpub] [EXTERNAL]Re: Ballot 190 - Recording BR Version Number

The original concern I raised was with the ballot 190 requirement that CAs 
begin to log the BR version number associated with the validation method used 
on each request. My concerns are:
1. The BR version doesn’t clearly indicate when a validation method has 
changed. As has been stated, the BR version number will surely increment for 
many reasons unrelated to validation methods. BR version 1.8.3 is likely to 
have the same meaning as version 2.1.6 in terms of validation methods.
2. CAs will review changes to the validation methods and come to different 
conclusions as to what changes require the BR version number to be incremented 
in their logs. Is a wording change material, even though I’m not updating the 
code? The ballot author should decide this.
3. CAs generally need to implement changes to methods prior to a BR version 
number even being assigned. I closely review ballots, but I don’t track BR 
version numbers.

This led me to propose a version number embedded in section 3.2.2.4 of the BRs 
that covers either all validation methods or one for each method – it doesn’t 
matter to me. This approach:
1. Provides clear guidance that the CA must update the version number they’re 
logging as part of implementing a particular change
2. 2. Allows CAs to make changes based on approved ballots rather than being 
dependent on BR version numbers
3. Doesn’t require a separate section of the BRs to be updated and kept in synch
4. Can easily be added to ballot 190 while we’re waiting for ballot 202

Thanks,

Wayne


On 8/1/17, 9:28 AM, "Public on behalf of Ben Wilson via Public" 
<public-boun...@cabforum.org on behalf of public@cabforum.org> wrote:

There are two sides to this - one is with the CAs, where they record what
method was used, and the other is at the CA/Browser Forum level, where 
someone
maintains a chart, or whatever, of validation methods in effect, and
historically which ones were effective during which periods.


-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org]
Sent: Tuesday, August 1, 2017 10:06 AM
To: Ben Wilson <ben.wil...@digicert.com>; CA/Browser Forum Public Discussion
List <public@cabforum.org>; Kirk Hall <kirk.h...@entrustdatacard.com>
Subject: Re: [cabfpub] [EXTERNAL]Re: Ballot 190 - Recording BR Version 
Number

On 01/08/17 17:00, Ben Wilson wrote:
> Are we talking about what the CA records in its database for the
> validation method used, or are we talking about annotating the BRs
> with a record of when a change was made?

I am raising the problem that if there is a list of changes made and it goes
out of sync with reality, then what do I, at Mozilla, do if a CA says 
"well, I
didn't realise that change had been made because it wasn't added to the
official list"?

There should be one and exactly one method of knowing when changes are made.

Earlier, although perhaps not in this thread, someone suggested independent
version numbers for each of the methods. That has a similar issue - there
should be one and exactly one method of recording what validation method was
used.

Gerv


___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [EXTERNAL]Re: Ballot 190 - Recording BR Version Number

[Ben Wilson via Public]

There are two sides to this - one is with the CAs, where they record what 
method was used, and the other is at the CA/Browser Forum level, where someone 
maintains a chart, or whatever, of validation methods in effect, and 
historically which ones were effective during which periods.


-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org]
Sent: Tuesday, August 1, 2017 10:06 AM
To: Ben Wilson ; CA/Browser Forum Public Discussion 
List ; Kirk Hall 
Subject: Re: [cabfpub] [EXTERNAL]Re: Ballot 190 - Recording BR Version Number

On 01/08/17 17:00, Ben Wilson wrote:
> Are we talking about what the CA records in its database for the
> validation method used, or are we talking about annotating the BRs
> with a record of when a change was made?

I am raising the problem that if there is a list of changes made and it goes 
out of sync with reality, then what do I, at Mozilla, do if a CA says "well, I 
didn't realise that change had been made because it wasn't added to the 
official list"?

There should be one and exactly one method of knowing when changes are made.

Earlier, although perhaps not in this thread, someone suggested independent 
version numbers for each of the methods. That has a similar issue - there 
should be one and exactly one method of recording what validation method was 
used.

Gerv


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

Re: [cabfpub] [EXTERNAL]Re: Ballot 190 - Recording BR Version Number

[Ben Wilson via Public]

Are we talking about what the CA records in its database for the  validation
method used, or are we talking about annotating the BRs with a record of
when a change was made?

-Original Message-
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase
Markham via Public
Sent: Tuesday, August 1, 2017 5:38 AM
To: Kirk Hall ; CA/Browser Forum Public
Discussion List 
Subject: Re: [cabfpub] [EXTERNAL]Re: Ballot 190 - Recording BR Version
Number

On 21/07/17 16:02, Kirk Hall via Public wrote:
>> The two responses (Gerv's and mine) are not in conflict, and there is no
harm in including the extra information in the BRs.  I'm a big believer in
helping people avoid mistakes when it's easy to do.

I don't believe that it's good for there to be two possible ways of
recording the relevant information. Either it should be mandated to record
the BR version number and method section number, or there should be some
other versioning mechanism - but not both.

I don't see the objection to BR version number and section number. If a new
version of the BRs is published which makes no changes to domain validation
methods (a common occurrence), then clearly:

BR 1.7.1/Section 3.2.2.4.5
is totally equivalent to
BR 1.7.2/Section 3.2.2.4.5

(because there are no changes to section 3.2.2.4.5) and so it doesn't matter
which of the two identifiers the CA records. The CA can continue to record
compliance with BR 1.7.1 as long as there are no material changes in any
future versions of the BRs which affect method 3.2.2.4.5.

Gerv
___
Public mailing list
Public@cabforum.org
https://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] Pre-Ballot 209 EV Liability

[Ben Wilson via Public]

The rationale is that it is already current practice by many CAs to limit 
their total liability for CA operations.  Also, not that this will save 
anybody from going out of business in the event of a serious breach, and I 
suspect that such CA would simply file for bankruptcy protection, but it does 
map the $5 Million liability to the $5 Million in Errors and Omissions 
liability.  Some other members can probably provide some additional reasons 
why this ballot is a good thing--not just for CAs.


-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org]
Sent: Monday, July 31, 2017 9:27 AM
To: Ben Wilson <ben.wil...@digicert.com>; CA/Browser Forum Public Discussion
List <public@cabforum.org>
Subject: Re: [cabfpub] Pre-Ballot 209 EV Liability

On 25/07/17 21:59, Ben Wilson via Public wrote:
> Here is another pre-ballot for discussion.

Can you explain the rationale for this ballot?

Gerv


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

Re: [cabfpub] Pre-Ballot 209 EV Liability

[Ben Wilson via Public]

Would this work?

 

Notwithstanding the foregoing, a CA MAY limit its liability to Subscribers or 
Relying Parties for legally recognized and provable claims to not less than: 
(1) one hundred thousand US dollars – aggregated across all claims, 
Subscribers, and Relying Parties – per EV Certificate; and/or (2) five million 
US dollars – aggregated across all claims, Subscribers, and Relying Parties – 
for all EV Certificates issued by the CA during any continuous 12-month period. 
These limitations are notwithstanding anything in the Baseline Requirements 
purportedly to the contrary.

 

From: Moudrick M. Dadashov [mailto:m...@ssc.lt] 
Sent: Tuesday, July 25, 2017 5:48 PM
To: Ben Wilson <ben.wil...@digicert.com>; CA/Browser Forum Public Discussion 
List <public@cabforum.org>
Subject: Re: [cabfpub] Pre-Ballot 209 EV Liability

 

Would you mind to show how it would sound now? :)

Thanks,
M.D.

On 7/26/2017 2:14 AM, Ben Wilson wrote:

And it should be an “and” or a “but”, but rephrased nevertheless.

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 

From: Ben Wilson 
Sent: Tuesday, July 25, 2017 5:11 PM
To: Ben Wilson  <mailto:ben.wil...@digicert.com> <ben.wil...@digicert.com>; 
CA/Browser Forum Public Discussion List  <mailto:public@cabforum.org> 
<public@cabforum.org>; Moudrick M. Dadashov  <mailto:m...@ssc.lt> <m...@ssc.lt>
Subject: RE: [cabfpub] Pre-Ballot 209 EV Liability

 

Never mind – I think I now see your point.  Not “up to” it needs to be “not 
less than $5 million.”  Would that make it clearer?

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ben Wilson via 
Public
Sent: Tuesday, July 25, 2017 5:10 PM
To: Moudrick M. Dadashov <m...@ssc.lt <mailto:m...@ssc.lt> >; CA/Browser Forum 
Public Discussion List <public@cabforum.org <mailto:public@cabforum.org> >
Subject: Re: [cabfpub] Pre-Ballot 209 EV Liability

 

It’s permissive – a CA MAY limit its liability.   Maybe we should say “up to $5 
million”.   Then, would that be clearer -  that it can be less than $5 million?

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 

From: Moudrick M. Dadashov [mailto:m...@ssc.lt] 
Sent: Tuesday, July 25, 2017 4:35 PM
To: Ben Wilson <ben.wil...@digicert.com <mailto:ben.wil...@digicert.com> >; 
CA/Browser Forum Public Discussion List <public@cabforum.org 
<mailto:public@cabforum.org> >
Subject: Re: [cabfpub] Pre-Ballot 209 EV Liability

 

With "and" I don't see its optional.

Again, just to understand the model: is per EV certificate amount is NOT fixed 
whereas 12-month continuous amount is the only option ($5 mln.)?

Thanks,
M.D.  

On 7/26/2017 1:28 AM, Ben Wilson wrote:

All of the provisions would provide optional caps that CAs could place on EV 
liability.  The 12-month $5 Million cap allows a CA to cap all EV liability to 
all those EV certificates issued within a single year.   

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 

From: Moudrick M. Dadashov [mailto:m...@ssc.lt] 
Sent: Tuesday, July 25, 2017 4:24 PM
To: Ben Wilson  <mailto:ben.wil...@digicert.com> <ben.wil...@digicert.com>; 
CA/Browser Forum Public Discussion List  <mailto:public@cabforum.org> 
<public@cabforum.org>
Subject: Re: [cabfpub] Pre-Ballot 209 EV Liability

 

Ok. Do I understand the intention correctly: to have a "floating liability" 
amount per EV certificate and "fixed liability" amount per continuous 12-month 
period?

Thanks,
M.D.

On 7/26/2017 1:10 AM, Ben Wilson wrote:

No. Because they MAY do both.  An “or” would mean that they have to choose 
between the two, which isn’t the intent.

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 

From: Moudrick M. Dadashov [mailto:m...@ssc.lt] 
Sent: Tuesday, July 25, 2017 4:09 PM
To: Ben Wilson  <mailto:ben.wil...@digicert.com> <ben.wil...@digicert.com>; 
CA/Browser Forum Public Discussion List  <mailto:public@cabforum.org> 
<public@cabforum.org>
Subject: Re: [cabfpub] Pre-Ballot 209 EV Liability

 

Hi Ben,

could it be "or" between (1) and (2)?

Thanks,
M.D.

On 7/25/2017 11:59 PM, Ben Wilson via Public wrote:

Here is another pre-ballot for discussion.

 

Ballot 209 - EV Liability

 

In Section 18 of the EV Guidelines, add the following sentences to the end of 
the first paragraph:

 

Notwithstanding the foregoing, a CA MAY limit its liability to Subscribers or 
Relying Parties for legally recognized and provable claims to: (1) one hundred 
thousand US dollars – aggregated across all claims, Subscribers, and Relying 
Parties – per EV Certificate; and (2) five million US dollars – aggregated 
across all claims, Subscribers, and Relying Parties – for all EV Certificates 
issued by the CA during any continuous 12-month period. These limitati

Re: [cabfpub] Pre-Ballot 209 EV Liability

[Ben Wilson via Public]

And it should be an “and” or a “but”, but rephrased nevertheless.

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 

From: Ben Wilson 
Sent: Tuesday, July 25, 2017 5:11 PM
To: Ben Wilson <ben.wil...@digicert.com>; CA/Browser Forum Public Discussion 
List <public@cabforum.org>; Moudrick M. Dadashov <m...@ssc.lt>
Subject: RE: [cabfpub] Pre-Ballot 209 EV Liability

 

Never mind – I think I now see your point.  Not “up to” it needs to be “not 
less than $5 million.”  Would that make it clearer?

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ben Wilson via 
Public
Sent: Tuesday, July 25, 2017 5:10 PM
To: Moudrick M. Dadashov <m...@ssc.lt <mailto:m...@ssc.lt> >; CA/Browser Forum 
Public Discussion List <public@cabforum.org <mailto:public@cabforum.org> >
Subject: Re: [cabfpub] Pre-Ballot 209 EV Liability

 

It’s permissive – a CA MAY limit its liability.   Maybe we should say “up to $5 
million”.   Then, would that be clearer -  that it can be less than $5 million?

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 

From: Moudrick M. Dadashov [mailto:m...@ssc.lt] 
Sent: Tuesday, July 25, 2017 4:35 PM
To: Ben Wilson <ben.wil...@digicert.com <mailto:ben.wil...@digicert.com> >; 
CA/Browser Forum Public Discussion List <public@cabforum.org 
<mailto:public@cabforum.org> >
Subject: Re: [cabfpub] Pre-Ballot 209 EV Liability

 

With "and" I don't see its optional.

Again, just to understand the model: is per EV certificate amount is NOT fixed 
whereas 12-month continuous amount is the only option ($5 mln.)?

Thanks,
M.D.  

On 7/26/2017 1:28 AM, Ben Wilson wrote:

All of the provisions would provide optional caps that CAs could place on EV 
liability.  The 12-month $5 Million cap allows a CA to cap all EV liability to 
all those EV certificates issued within a single year.   

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 

From: Moudrick M. Dadashov [mailto:m...@ssc.lt] 
Sent: Tuesday, July 25, 2017 4:24 PM
To: Ben Wilson  <mailto:ben.wil...@digicert.com> <ben.wil...@digicert.com>; 
CA/Browser Forum Public Discussion List  <mailto:public@cabforum.org> 
<public@cabforum.org>
Subject: Re: [cabfpub] Pre-Ballot 209 EV Liability

 

Ok. Do I understand the intention correctly: to have a "floating liability" 
amount per EV certificate and "fixed liability" amount per continuous 12-month 
period?

Thanks,
M.D.

On 7/26/2017 1:10 AM, Ben Wilson wrote:

No. Because they MAY do both.  An “or” would mean that they have to choose 
between the two, which isn’t the intent.

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 

From: Moudrick M. Dadashov [mailto:m...@ssc.lt] 
Sent: Tuesday, July 25, 2017 4:09 PM
To: Ben Wilson  <mailto:ben.wil...@digicert.com> <ben.wil...@digicert.com>; 
CA/Browser Forum Public Discussion List  <mailto:public@cabforum.org> 
<public@cabforum.org>
Subject: Re: [cabfpub] Pre-Ballot 209 EV Liability

 

Hi Ben,

could it be "or" between (1) and (2)?

Thanks,
M.D.

On 7/25/2017 11:59 PM, Ben Wilson via Public wrote:

Here is another pre-ballot for discussion.

 

Ballot 209 - EV Liability

 

In Section 18 of the EV Guidelines, add the following sentences to the end of 
the first paragraph:

 

Notwithstanding the foregoing, a CA MAY limit its liability to Subscribers or 
Relying Parties for legally recognized and provable claims to: (1) one hundred 
thousand US dollars – aggregated across all claims, Subscribers, and Relying 
Parties – per EV Certificate; and (2) five million US dollars – aggregated 
across all claims, Subscribers, and Relying Parties – for all EV Certificates 
issued by the CA during any continuous 12-month period. These limitations are 
notwithstanding anything in the Baseline Requirements purportedly to the 
contrary.

 

Such that Section 18 of the EV Guidelines would read:

 

CAs MAY limit their liability as described in Section 9.8 of the Baseline 
Requirements except that a CA MAY NOT limit its liability to Subscribers or 
Relying Parties for legally recognized and provable claims to a monetary amount 
less than two thousand US dollars per Subscriber or Relying Party per EV 
Certificate. Notwithstanding the foregoing, a CA MAY limit its liability to 
Subscribers or Relying Parties for legally recognized and provable claims to: 
(1) one hundred thousand US dollars – aggregated across all claims, 
Subscribers, and Relying Parties – per EV Certificate; and (2) five million US 
dollars – aggregated across all claims, Subscribers, and Relying Parties – for 
all EV Certificates issued by the CA during any continuous 12-month period. 
These limitations are notwithstanding anything in the Baseline Requirements 
purportedly to the contrary.

 

A CA's indemnification obligatio

Re: [cabfpub] Pre-Ballot 209 EV Liability

[Ben Wilson via Public]

Never mind – I think I now see your point.  Not “up to” it needs to be “not 
less than $5 million.”  Would that make it clearer?

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ben Wilson via 
Public
Sent: Tuesday, July 25, 2017 5:10 PM
To: Moudrick M. Dadashov <m...@ssc.lt>; CA/Browser Forum Public Discussion List 
<public@cabforum.org>
Subject: Re: [cabfpub] Pre-Ballot 209 EV Liability

 

It’s permissive – a CA MAY limit its liability.   Maybe we should say “up to $5 
million”.   Then, would that be clearer -  that it can be less than $5 million?

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 

From: Moudrick M. Dadashov [mailto:m...@ssc.lt] 
Sent: Tuesday, July 25, 2017 4:35 PM
To: Ben Wilson <ben.wil...@digicert.com <mailto:ben.wil...@digicert.com> >; 
CA/Browser Forum Public Discussion List <public@cabforum.org 
<mailto:public@cabforum.org> >
Subject: Re: [cabfpub] Pre-Ballot 209 EV Liability

 

With "and" I don't see its optional.

Again, just to understand the model: is per EV certificate amount is NOT fixed 
whereas 12-month continuous amount is the only option ($5 mln.)?

Thanks,
M.D.  

On 7/26/2017 1:28 AM, Ben Wilson wrote:

All of the provisions would provide optional caps that CAs could place on EV 
liability.  The 12-month $5 Million cap allows a CA to cap all EV liability to 
all those EV certificates issued within a single year.   

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 

From: Moudrick M. Dadashov [mailto:m...@ssc.lt] 
Sent: Tuesday, July 25, 2017 4:24 PM
To: Ben Wilson  <mailto:ben.wil...@digicert.com> <ben.wil...@digicert.com>; 
CA/Browser Forum Public Discussion List  <mailto:public@cabforum.org> 
<public@cabforum.org>
Subject: Re: [cabfpub] Pre-Ballot 209 EV Liability

 

Ok. Do I understand the intention correctly: to have a "floating liability" 
amount per EV certificate and "fixed liability" amount per continuous 12-month 
period?

Thanks,
M.D.



On 7/26/2017 1:10 AM, Ben Wilson wrote:

No. Because they MAY do both.  An “or” would mean that they have to choose 
between the two, which isn’t the intent.

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 

From: Moudrick M. Dadashov [mailto:m...@ssc.lt] 
Sent: Tuesday, July 25, 2017 4:09 PM
To: Ben Wilson  <mailto:ben.wil...@digicert.com> <ben.wil...@digicert.com>; 
CA/Browser Forum Public Discussion List  <mailto:public@cabforum.org> 
<public@cabforum.org>
Subject: Re: [cabfpub] Pre-Ballot 209 EV Liability

 

Hi Ben,

could it be "or" between (1) and (2)?

Thanks,
M.D.

On 7/25/2017 11:59 PM, Ben Wilson via Public wrote:

Here is another pre-ballot for discussion.

 

Ballot 209 - EV Liability

 

In Section 18 of the EV Guidelines, add the following sentences to the end of 
the first paragraph:

 

Notwithstanding the foregoing, a CA MAY limit its liability to Subscribers or 
Relying Parties for legally recognized and provable claims to: (1) one hundred 
thousand US dollars – aggregated across all claims, Subscribers, and Relying 
Parties – per EV Certificate; and (2) five million US dollars – aggregated 
across all claims, Subscribers, and Relying Parties – for all EV Certificates 
issued by the CA during any continuous 12-month period. These limitations are 
notwithstanding anything in the Baseline Requirements purportedly to the 
contrary.

 

Such that Section 18 of the EV Guidelines would read:

 

CAs MAY limit their liability as described in Section 9.8 of the Baseline 
Requirements except that a CA MAY NOT limit its liability to Subscribers or 
Relying Parties for legally recognized and provable claims to a monetary amount 
less than two thousand US dollars per Subscriber or Relying Party per EV 
Certificate. Notwithstanding the foregoing, a CA MAY limit its liability to 
Subscribers or Relying Parties for legally recognized and provable claims to: 
(1) one hundred thousand US dollars – aggregated across all claims, 
Subscribers, and Relying Parties – per EV Certificate; and (2) five million US 
dollars – aggregated across all claims, Subscribers, and Relying Parties – for 
all EV Certificates issued by the CA during any continuous 12-month period. 
These limitations are notwithstanding anything in the Baseline Requirements 
purportedly to the contrary.

 

A CA's indemnification obligations and a Root CA’s obligations with respect to 
subordinate CAs are set forth in Section 9.9 of the Baseline Requirements.

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 







___
Public mailing list
Public@cabforum.org <mailto:Public@cabforum.org> 
https://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] Pre-Ballot 209 EV Liability

[Ben Wilson via Public]

All of the provisions would provide optional caps that CAs could place on EV 
liability.  The 12-month $5 Million cap allows a CA to cap all EV liability to 
all those EV certificates issued within a single year.   

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 

From: Moudrick M. Dadashov [mailto:m...@ssc.lt] 
Sent: Tuesday, July 25, 2017 4:24 PM
To: Ben Wilson <ben.wil...@digicert.com>; CA/Browser Forum Public Discussion 
List <public@cabforum.org>
Subject: Re: [cabfpub] Pre-Ballot 209 EV Liability

 

Ok. Do I understand the intention correctly: to have a "floating liability" 
amount per EV certificate and "fixed liability" amount per continuous 12-month 
period?

Thanks,
M.D.



On 7/26/2017 1:10 AM, Ben Wilson wrote:

No. Because they MAY do both.  An “or” would mean that they have to choose 
between the two, which isn’t the intent.

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 

From: Moudrick M. Dadashov [mailto:m...@ssc.lt] 
Sent: Tuesday, July 25, 2017 4:09 PM
To: Ben Wilson  <mailto:ben.wil...@digicert.com> <ben.wil...@digicert.com>; 
CA/Browser Forum Public Discussion List  <mailto:public@cabforum.org> 
<public@cabforum.org>
Subject: Re: [cabfpub] Pre-Ballot 209 EV Liability

 

Hi Ben,

could it be "or" between (1) and (2)?

Thanks,
M.D.

On 7/25/2017 11:59 PM, Ben Wilson via Public wrote:

Here is another pre-ballot for discussion.

 

Ballot 209 - EV Liability

 

In Section 18 of the EV Guidelines, add the following sentences to the end of 
the first paragraph:

 

Notwithstanding the foregoing, a CA MAY limit its liability to Subscribers or 
Relying Parties for legally recognized and provable claims to: (1) one hundred 
thousand US dollars – aggregated across all claims, Subscribers, and Relying 
Parties – per EV Certificate; and (2) five million US dollars – aggregated 
across all claims, Subscribers, and Relying Parties – for all EV Certificates 
issued by the CA during any continuous 12-month period. These limitations are 
notwithstanding anything in the Baseline Requirements purportedly to the 
contrary.

 

Such that Section 18 of the EV Guidelines would read:

 

CAs MAY limit their liability as described in Section 9.8 of the Baseline 
Requirements except that a CA MAY NOT limit its liability to Subscribers or 
Relying Parties for legally recognized and provable claims to a monetary amount 
less than two thousand US dollars per Subscriber or Relying Party per EV 
Certificate. Notwithstanding the foregoing, a CA MAY limit its liability to 
Subscribers or Relying Parties for legally recognized and provable claims to: 
(1) one hundred thousand US dollars – aggregated across all claims, 
Subscribers, and Relying Parties – per EV Certificate; and (2) five million US 
dollars – aggregated across all claims, Subscribers, and Relying Parties – for 
all EV Certificates issued by the CA during any continuous 12-month period. 
These limitations are notwithstanding anything in the Baseline Requirements 
purportedly to the contrary.

 

A CA's indemnification obligations and a Root CA’s obligations with respect to 
subordinate CAs are set forth in Section 9.9 of the Baseline Requirements.

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 







___
Public mailing list
Public@cabforum.org <mailto:Public@cabforum.org> 
https://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] [EXTERNAL]Re: Ballot 190 - Recording BR Version Number

[Ben Wilson via Public]

Maybe someone could provide an example of how the BR version number would 
appear at the  end of each validation method?  For example, would it look like 
this?
[BR 1.5.0]  - with the implication that the method was allowed as of BR v. 
1.5.0 going forward until the current version of the BRs?  If the method were 
changed, would someone need to keep track that the language was XYZ from 
version 1.4.6 through version 1.5.4?
Thanks,
Ben

-Original Message-
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Friday, July 21, 2017 9:08 AM
To: Kirk Hall ; CA/Browser Forum Public 
Discussion List 
Subject: Re: [cabfpub] [EXTERNAL]Re: Ballot 190 - Recording BR Version Number

Hi Kirk,

As we saw from the discussions of Ballot 190, the inclusion of additional 
information "for clarity's sake" can have the deleterious side-effect of 
changing both the meaning and interpretation. The clarifications that had 
previously been proposed had notable issues they introduced.

So I don't think we can say there is no harm - and, in general, it means even 
more work to maintain these documents - so I'm hoping we can find a situation 
in which there is a single, well-understood path, rather than attempting to 
restate it several times. Given that these represent technical standards 
documents, and understanding that it takes a degree of professional expertise 
to understand and interpret them (much like any other standards document), it 
doesn't seem entirely unfair to suggest that there may be elements that are 
difficult for the lay-person, provided that they're unambiguous for the 
practitioners.

On Fri, Jul 21, 2017 at 11:02 AM, Kirk Hall via Public  
wrote:
> Meant for public list -- see my response below.
>
> -Original Message-
> From: Ryan Sleevi [mailto:sle...@google.com]
> Sent: Thursday, July 20, 2017 6:09 PM
> To: Kirk Hall 
> Subject: Re: [EXTERNAL]Re: [cabfpub] Ballot 190 - Recording BR Version 
> Number
>
> Hi Kirk,
>
> Did you mean to omit the list?
>
> On Thu, Jul 20, 2017 at 9:08 PM, Kirk Hall  
> wrote:
>> The two responses (Gerv's and mine) are not in conflict, and there is no 
>> harm in including the extra information in the BRs.  I'm a big believer in 
>> helping people avoid mistakes when it's easy to do.
>>
>> -Original Message-
>> From: Ryan Sleevi [mailto:sle...@google.com]
>> Sent: Thursday, July 20, 2017 6:02 PM
>> To: Kirk Hall ; CA/Browser Forum 
>> Public Discussion List 
>> Cc: Wayne Thayer 
>> Subject: [EXTERNAL]Re: [cabfpub] Ballot 190 - Recording BR Version 
>> Number
>>
>> Kirk,
>>
>> Given that the Forum already publishes its Ballots - and keeps track of 
>> changes within the documents - and given CAs are already required to 
>> annually review their CP/CPS (in addition to following the current published 
>> version), do you believe Gerv's response is not a perfectly reasonable and 
>> easy to accomplish approach?
>>
>> It would be useful to understand, given all the existing tools and 
>> practices, what's missing.
>>
>> On Thu, Jul 20, 2017 at 8:19 PM, Kirk Hall via Public  
>> wrote:
>>> Wayne, I think your idea has merit in this special situation – and 
>>> it’s something we can probably accomplish without a ballot.
>>>
>>>
>>>
>>> Statute books commonly have notations at the end of each statute 
>>> showing all the times the statute was amended – often it will show 
>>> year and public law number (in “reverse” order with the most recent
>>> first) so users can go back and find each law that affected a current 
>>> statute.
>>>
>>>
>>>
>>> When we compile the BRs after Ballot 190 passes, we can put the BR 
>>> version number where each of the 10 methods was LAST amended by the 
>>> Forum.  That way, a CA who looks at the most recent BR compilation 
>>> will know which methods have been recently amended, and which have 
>>> not.  No one has to use this information, but it would be easy to 
>>> include in a footnote at the end of BR 3.2.2.4, and update when there is 
>>> any further change.
>>>
>>>
>>>
>>> Ben and I will discuss after Ballot 190 has passed.
>>>
>>>
>>>
>>> From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Wayne 
>>> Thayer via Public
>>> Sent: Tuesday, July 18, 2017 6:32 PM
>>> To: public@cabforum.org
>>> Subject: [EXTERNAL][cabfpub] Ballot 190 - Recording BR Version 
>>> Number
>>>
>>>
>>>
>>> Ballot 190 Includes the following statement in 3.2.2.4:
>>>
>>>
>>>
>>> The CA SHALL maintain a record of which domain validation method, 
>>> including relevant BR version number, they used to validate every domain.
>>>
>>>
>>>
>>> While I understand the logic behind this, I’m concerned about the 
>>> “relevant BR version number”. This could be interpreted in a number of 
>>> 

[cabfpub] CABF Plenary Teleconference Calls

[Ben Wilson via Public]

All,

 

If it's alright, and for the benefit of members located in Asia, I'm going
to start posting the WebEx recordings of CAB Forum plenary meeting calls to
the wiki.  

Access to the recording of today's call is available here:
https://cabforum.org/wiki/Teleconference%20recordings 


Ben



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

Re: [cabfpub] Ballot 202 - Underscore and Wildcard Characters

[Ben Wilson via Public]

DigiCert votes “Yes” 

 

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ben Wilson via 
Public
Sent: Wednesday, July 19, 2017 4:34 PM
To: Peter Bowen <p...@amzn.com>; CA/Browser Forum Public Discussion List 
<public@cabforum.org>; Ryan Sleevi <sle...@google.com>
Subject: Re: [cabfpub] Ballot 202 - Underscore and Wildcard Characters

 

Also, I have capitalized “Domain Name” in the definition of “Domain Label”, as 
shown below and in the attached PDF document.

 

On Jul 19, 2017, at 3:52 PM, Peter Bowen <p...@amzn.com <mailto:p...@amzn.com> 
> wrote:

 

One more update before voting starts, based on a request from Adriano.  The 
definition of the term Wildcard Domain Name has been updated.

 

On Jul 18, 2017, at 8:28 PM, Peter Bowen <p...@amzn.com <mailto:p...@amzn.com> 
> wrote:

 

Thanks to all who provided comments.  I’ve integrated the feedback from Kirk, 
Geoff, and Wayne, including using the definitions that Geoff proposed.  BR text 
that has changed is in red.  Additionally we dropping the proposed change for 
fully qualified domain name.

 

Ryan and Ben have agreed to these changes. Voting is scheduled to start in 
about 18 hours.

 

Thanks for the all the feedback!

 

On Jul 12, 2017, at 10:24 AM, Ben Wilson via Public <public@cabforum.org 
<mailto:public@cabforum.org> > wrote:

 

Ballot 202 - Underscore and Wildcard Characters

The current Baseline Requirements do not expressly allow underscore characters 
in Subject Alternative Names. This ballot seeks to clarify that one or more 
underscore characters (“_”) are allowed in FQDNs. In many places it also 
replaces the term "FQDN" with "Domain Name" because "Domain Name" now means 
either "FQDN" or "Wildcard Domain Name". The ballot clarifies validation of 
wildcard domain names. It also cleans up some of the language in Sections 
3.2.2.4 and 7.1.4.2.1 of the Baseline Requirements. 

The following motion has been proposed by Ben Wilson of DigiCert and endorsed 
by Peter Bowen of Amazon and Ryan Sleevi of Google to introduce new Final 
Maintenance Guidelines for the "Baseline Requirements Certificate Policy for 
the Issuance and Management of Publicly-Trusted Certificates" (Baseline 
Requirements). 

--Motion Begins-- 

A. In Sections 1.3.2, 1.6 (Base Domain Name), 2.2, 3.2.2.4, 3.2.2.4.5, 
3.2.2.4.6, 3.2.2.4.10, 3.2.2.4.11, 4.2.1, 4.9.1.1.6, and 4.9.11 of the Baseline 
Requirements, REPLACE the words "Fully Qualified Domain Name" and "FQDN" with 
"Domain Name". 

B. In Section 1.6.1 of the Baseline Requirements, in the definition for 
"Authorization Domain Name”, replace “FQDN” with “Domain Name” and change the 
third sentence to utilize the term “Wildcard Domain Name” such that the 
definition reads as follows: The Domain Name used to obtain authorization for 
certificate issuance for a given Domain Name. The CA may use the Domain Name 
returned from a DNS CNAME lookup as the Domain Name for the purposes of domain 
validation. If the Domain Name is a Wildcard Domain Name, then the CA MUST 
remove “*.” from the left most portion of the requested Domain Name. The CA may 
prune zero or more labels from left to right until encountering a Base Domain 
Name and may use any one of the intermediate values for the purpose of domain 
validation. 

C. In Section 1.6.1 of the Baseline Requirements, INSERT the following 
definition: "Domain Label: A label of a Domain Name, as defined in RFC 5890 
section 2.2; for example, the Domain Name "www.example.com 
<http://www.example.com/> " is composed of three labels: "www", "example", and 
"com”. " 

D. In Section 1.6.1 of the Baseline Requirements, REPLACE the definition for 
"Domain Name" with the following: A string which is a ‘domain name’, as defined 
in RFC 5890 section 2.2, with Domain Labels separated by dots, or a Wildcard 
Domain Name.  For example “www.example.com <http://www.example.com/> ” and 
“*.example.net <http://example.net/> ” are Domain Names. 

E. In Section 1.6.1 of the Baseline Requirements, DO NOT CHANGE the definition 
for "Fully-Qualified Domain Name”

F. In Section 1.6.1 of the Baseline Requirements, REPLACE the definition for 
"Reserved IP Address" with the following: An IPv4 or IPv6 address that the IANA 
has "False" for Globally Reachable in either of the IANA Special-Purpose IP 
Address Registries: 

 
<https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml>
 
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
 or 

 
<https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml>
 
https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

G. In Se

Re: [cabfpub] Ballot 202 - Underscore and Wildcard Characters

[Ben Wilson via Public]

Shortly I’ll circulate a full version of the Baseline Requirements redlined 
with the changes made by this ballot.

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Peter Bowen via 
Public
Sent: Wednesday, July 19, 2017 3:49 PM
To: Ben Wilson <ben.wil...@digicert.com>; CA/Browser Forum Public Discussion 
List <public@cabforum.org>; Ryan Sleevi <sle...@google.com>
Subject: Re: [cabfpub] Ballot 202 - Underscore and Wildcard Characters

 

One more update before voting starts, based on a request from Adriano.  The 
definition of the term Wildcard Domain Name has been updated.

 

On Jul 18, 2017, at 8:28 PM, Peter Bowen <p...@amzn.com <mailto:p...@amzn.com> 
> wrote:

 

Thanks to all who provided comments.  I’ve integrated the feedback from Kirk, 
Geoff, and Wayne, including using the definitions that Geoff proposed.  BR text 
that has changed is in red.  Additionally we dropping the proposed change for 
fully qualified domain name.

 

Ryan and Ben have agreed to these changes. Voting is scheduled to start in 
about 18 hours.

 

Thanks for the all the feedback!

 

On Jul 12, 2017, at 10:24 AM, Ben Wilson via Public <public@cabforum.org 
<mailto:public@cabforum.org> > wrote:

 

Ballot 202 - Underscore and Wildcard Characters

The current Baseline Requirements do not expressly allow underscore characters 
in Subject Alternative Names. This ballot seeks to clarify that one or more 
underscore characters (“_”) are allowed in FQDNs. In many places it also 
replaces the term "FQDN" with "Domain Name" because "Domain Name" now means 
either "FQDN" or "Wildcard Domain Name". The ballot clarifies validation of 
wildcard domain names. It also cleans up some of the language in Sections 
3.2.2.4 and 7.1.4.2.1 of the Baseline Requirements. 

The following motion has been proposed by Ben Wilson of DigiCert and endorsed 
by Peter Bowen of Amazon and Ryan Sleevi of Google to introduce new Final 
Maintenance Guidelines for the "Baseline Requirements Certificate Policy for 
the Issuance and Management of Publicly-Trusted Certificates" (Baseline 
Requirements). 

--Motion Begins-- 

A. In Sections 1.3.2, 1.6 (Base Domain Name), 2.2, 3.2.2.4, 3.2.2.4.5, 
3.2.2.4.6, 3.2.2.4.10, 3.2.2.4.11, 4.2.1, 4.9.1.1.6, and 4.9.11 of the Baseline 
Requirements, REPLACE the words "Fully Qualified Domain Name" and "FQDN" with 
"Domain Name". 

B. In Section 1.6.1 of the Baseline Requirements, in the definition for 
"Authorization Domain Name”, replace “FQDN” with “Domain Name” and change the 
third sentence to utilize the term “Wildcard Domain Name” such that the 
definition reads as follows: The Domain Name used to obtain authorization for 
certificate issuance for a given Domain Name. The CA may use the Domain Name 
returned from a DNS CNAME lookup as the Domain Name for the purposes of domain 
validation. If the Domain Name is a Wildcard Domain Name, then the CA MUST 
remove “*.” from the left most portion of the requested Domain Name. The CA may 
prune zero or more labels from left to right until encountering a Base Domain 
Name and may use any one of the intermediate values for the purpose of domain 
validation. 

C. In Section 1.6.1 of the Baseline Requirements, INSERT the following 
definition: "Domain Label: A label of a domain name, as defined in RFC 5890 
section 2.2; for example, the domain name "www.example.com 
<http://www.example.com/> " is composed of three labels: "www", "example", and 
"com”. " 

D. In Section 1.6.1 of the Baseline Requirements, REPLACE the definition for 
"Domain Name" with the following: A string which is a ‘domain name’, as defined 
in RFC 5890 section 2.2, with labels separated by dots, or a Wildcard Domain 
Name.  For example “www.example.com <http://www.example.com/> ” and 
“*.example.net <http://example.net/> ” are Domain Names. 

E. In Section 1.6.1 of the Baseline Requirements, DO NOT CHANGE the definition 
for "Fully-Qualified Domain Name”

F. In Section 1.6.1 of the Baseline Requirements, REPLACE the definition for 
"Reserved IP Address" with the following: An IPv4 or IPv6 address that the IANA 
has "False" for Globally Reachable in either of the IANA Special-Purpose IP 
Address Registries: 

 
<https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml>
 
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
 or 

 
<https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml>
 
https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

G. In Section 1.6.1 of the Baseline Requirements, REPLACE the definition for 
"Wildca

Re: [cabfpub] Ballot 204: Forbid DTPs from doing Domain/IP Ownership Validation

[Ben Wilson via Public]

DigiCert votes “yes” on Ballot 204.



From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase Markham 
via Public
Sent: Monday, June 26, 2017 8:18 AM
To: CABFPub >
Subject: [cabfpub] Ballot 204: Forbid DTPs from doing Domain/IP Ownership 
Validation



Ballot 204: Forbid DTPs from doing Domain/IP Ownership Validation

Purpose of Ballot: At the moment, CAs are permitted to delegate the process of 
domain and IP address validation. However, permitting such delegations is 
problematic due to the way audits work - the auditing of such work may or may 
not be required and, if it is, those audit documents may not make it back to 
root programs for consideration. Although the audit situation also needs 
fixing, domain validation is an important enough component of a CA's core 
competencies that it seems wiser to remove it from the larger problem and 
forbid its delegation. The purpose of this ballot is to ensure that CAs or 
their Affiliates are always the ones performing domain/IP address ownership 
validation for certificates that CA is responsible for.

The following motion has been proposed by Gervase Markham of Mozilla and 
endorsed by Ryan Sleevi of Google and Mike Reilly of Microsoft:

-- MOTION BEGINS --

This motion modifies the Baseline Requirements.

0) In section 1.6.1, augment the definition of "Delegated Third Party" as 
follows:

Delegated Third Party: A natural person or Legal Entity that is not the CA, and 
whose activities are not within the scope of the appropriate CA audits, but is 
authorized by the CA to assist in the Certificate Management Process by 
performing or fulfilling one or more of the CA requirements found herein.

1) In section 1.3.2, replace the following sentence:

"The CA MAY delegate the performance of all, or any part, of Section 3.2 
requirements to a Delegated Third Party, provided that the process as a whole 
fulfills all of the requirements of Section 3.2."

with:

"With the exception of sections 3.2.2.4 and 3.2.2.5, the CA MAY delegate the 
performance of all, or any part, of Section 3.2 requirements to a Delegated 
Third Party, provided that the process as a whole fulfills all of the 
requirements of Section 3.2."

2) In sections 3.2.2.4, replace the paragraph beginning "The CA SHALL confirm 
that" with the following:

"The CA SHALL confirm that, as of the date the Certificate issues, the CA has 
validated each Fully‐Qualified Domain Name (FQDN) listed in the Certificate 
using at least one of the methods listed below, or is within the Domain 
Namespace of a Fully-Qualified Domain Name (FQDN) that has been validated using 
at least one of the methods listed below (not including the method defined in 
section 3.2.2.4.8)."

3) In section 3.2.2.4.6, remove the words "or Delegated Third Party".

4) In section 3.2.2.4.11 (if still present in the text at the time the ballot 
passes), replace the following text:

"either the CA or a Delegated Third Party"

with:

"the CA"

5) In section 8.4, remove the paragraph beginning: "If a Delegated Third Party 
is not currently audited...".

6) In section 8.4, replace the following text:

"If the CA is not using one of the above procedures and the Delegated Third 
Party is not an Enterprise RA, then"

with:

"For Delegated Third Parties which are not Enterprise RAs, ".

-- MOTION ENDS --



The procedure for approval of this Final Maintenance Guideline ballot is as 
follows:



BALLOT 204

Status: Final Maintenance Guideline

Start time (23:00 UTC)

End time (23:00 UTC)

Discussion (7 to 14 days)

27 June

4 July

Vote for approval (7 days)

4 July

11 July

If vote approves ballot: Review Period (Chair to send Review Notice) (30 days).

If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be 
created.

If no Exclusion Notices filed, ballot becomes effective at end of Review Period.

Upon filing of Review Notice by Chair

30 days after filing of Review Notice by Chair



From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final Maintenance 
Guideline, such ballot will include a redline or comparison showing the set of 
changes from the Final Guideline section(s) intended to become a Final 
Maintenance Guideline, and need not include a copy of the full set of 
guidelines.  Such redline or comparison shall be made against the Final 
Guideline section(s) as they exist at the time a ballot is proposed, and need 
not take into consideration other ballots that may be proposed subsequently, 
except as provided in Bylaw Section 2.3(j).



Votes must be cast by posting an on-list reply to this thread on the Public 
list.  A vote in favor of the motion must indicate a clear 'yes' in the 
response. A vote against must indicate a clear 'no' in the response. A vote to 
abstain must indicate a clear 'abstain' in the response. Unclear responses will 
not be counted. The latest vote received from any representative of a voting 
member before the close of the