[cabfpub] Draft Working Group Charter for Network Security WG

Thu Nov 18 22:05:12 UTC 2021

I think this is probably fine.  Getting coordinated compliance with the NCSSRs across the various WGs may be best handled by one or more root programs, instead of the WGs themselves, which have challenges here due to the intentional segmentation.

-Tim

From: Ben Wilson <bwilson at mozilla.com> 
Sent: Monday, November 15, 2021 11:28 AM
To: Clint Wilson <clintw at apple.com>
Cc: Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>; CABforum1 <public at cabforum.org>; Tim Hollebeek <tim.hollebeek at digicert.com>
Subject: Re: [cabfpub] Draft Working Group Charter for Network Security WG

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 <clintw at apple.com <mailto:clintw at apple.com> > 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 at cabforum.org <mailto:public at 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  <mailto:bwilson at mozilla.com> <bwilson at mozilla.com> 
Sent: Wednesday, November 10, 2021 10:31 AM
To: Dimitris Zacharopoulos  <mailto:dzacharo at harica.gr> <dzacharo at harica.gr>
Cc: CABforum1  <mailto:public at cabforum.org> <public at cabforum.org>; Tim Hollebeek  <mailto:tim.hollebeek at digicert.com> <tim.hollebeek at digicert.com>
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 <dzacharo at harica.gr <mailto:dzacharo at harica.gr> > 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 <public at cabforum.org <mailto:public at cabforum.org> >:

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 <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> > 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 <public-bounces at cabforum.org <mailto:public-bounces at cabforum.org> > On Behalf Of Ben Wilson via Public
Sent: Thursday, October 28, 2021 12:35 PM
To: CABforum1 <public at cabforum.org <mailto:public at cabforum.org> >
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 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 Issuers must be in favor of the ballot and more than 50% of the votes cast by the Certificate Consumers 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 (cumulative, regardless of Class) that have participated in the previous three NetSec WG Meetings or Teleconferences (not counting subcommittee meetings thereof). For transition purposes, if three meetings have not yet occurred, then quorum is ten (10).

7. Leadership

Chair – Clint Wilson shall be the initial Chair of the NetSec WG.

Vice-Chair -  David Kluge shall be the initial Vice-Chair of the NetSec WG.

Term.  The Chair and Vice-Chair will serve until October 31, 2022, or until they are replaced, resign, or are otherwise disqualified. Thereafter, elections shall be held for chair and vice chair every two years in coordination with the Forum’s election process and in conjunction with its election cycle. Voting shall occur in accordance with Bylaw 4.1(c). In the event of a midterm vacancy, the NetSec WG will hold a special election and the selected candidate will serve the remainder of the existing term.

8. Communication - NetSec WG communications and documents shall be posted on mailing-lists where the mail-archives are publicly accessible, and the NetSec WG shall publish minutes of its meetings to the Forum’s website.

9.  IPR Policy - The CA/Browser Forum Intellectual Rights Policy, v. 1.3 or later, shall apply to all Working Group activity.

10. Other Organizational Matters

Reserved.

Effect of Forum Bylaws Amendment on Working Group - In the event that Forum Bylaws are amended to add or modify general rules governing Forum Working Groups and how they operate, such provisions of the Bylaws take precedence over this charter.

_______________________________________________ 
Public mailing list 
Public at cabforum.org <mailto:Public at cabforum.org>  
https://lists.cabforum.org/mailman/listinfo/public

_______________________________________________
Public mailing list
 <mailto:Public at cabforum.org> Public at cabforum.org
 <https://lists.cabforum.org/mailman/listinfo/public> https://lists.cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20211118/ba9c2481/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20211118/ba9c2481/attachment-0001.p7s>