Re: [cabfpub] Draft Working Group Charter for Network Security WG
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 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 Grou
Re: [cabfpub] Draft Working Group Charter for Network Security WG
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 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
[cabfpub] Final CA/Browser Forum agenda - Thursday, November 11, 2021 at 11:30 am Eastern Time
Here is the final agenda for this week's meeting. 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 (Oct 28th). F2F Minutes status 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 Dean 0:04 11:55 11:59 9 Any Other Business 0:01 11:59 12:00 10. Next call: No call on Nov 25th (Thanksgiving) Adjourn; F2F Meeting Schedule: * 2022: Feb 22-24 - Salt Lake City, June 6-8 - Poland, Oct 24-26 - Berlin smime.p7s Description: S/MIME cryptographic signature ___ Public mailing list Public@cabforum.org https://lists.cabforum.org/mailman/listinfo/public
