[cabfpub] Draft Working Group Charter for Network Security WG
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Thu Nov 11 16:30:13 UTC 2021
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>
> *Sent:* Wednesday, November 10, 2021 10:31 AM
> *To:* Dimitris Zacharopoulos <dzacharo at harica.gr>
> *Cc:* CABforum1 <public at cabforum.org>; Tim Hollebeek
> <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20211111/1af4ae55/attachment-0001.html>
More information about the Public
mailing list