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