[cabfpub] Draft Working Group Charter for Network Security WG

Wed Nov 17 04:25:50 UTC 2021

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 <public at cabforum.org>
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 <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> 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 <bwilson at mozilla.com> <bwilson at mozilla.com>
>> *Sent:* Wednesday, November 10, 2021 10:31 AM
>> *To:* Dimitris Zacharopoulos <dzacharo at harica.gr> <dzacharo at harica.gr>
>> *Cc:* CABforum1 <public at cabforum.org> <public at cabforum.org>; Tim
>> Hollebeek <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>
>> 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>:
>>
>> 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>
>> 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> *On Behalf Of *Ben Wilson
>> via Public
>> *Sent:* Thursday, October 28, 2021 12:35 PM
>> *To:* CABforum1 <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
>> https://lists.cabforum.org/mailman/listinfo/public
>>
>>
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://lists.cabforum.org/mailman/listinfo/public
>>
>>
>> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20211116/26e992d5/attachment-0001.html>