I don't think the proposed charter does that then :) In copying from the other proposals, it looks to explicitly propose the creation of a new, separate, and wholly independent document - hence the objection, and which now that we understand the basis of that objection, seems like we agree on why it'd be objectionable :)
On Fri, May 18, 2018 at 11:26 AM, Tim Hollebeek <[email protected]> wrote: > That is accurate. > > > > -Tim > > > > *From:* Peter Bowen [mailto:[email protected]] > *Sent:* Friday, May 18, 2018 11:26 AM > *To:* Tim Hollebeek <[email protected]>; CA/Browser Forum Public > Discussion List <[email protected]> > *Cc:* Jos Purvis (jopurvis) <[email protected]>; Ryan Sleevi < > [email protected]> > > *Subject:* Re: [cabfpub] For Discussion: S/MIME Working Group Charter > > > > Tim, > > > > It seems your intent was to call out in the charter that any Guideline > needs to include not only validation requirements but CA infrastructure > security requirements as well. Is that accurate? > > > > Thanks, > > Peter > > > > On May 18, 2018, at 8:23 AM, Tim Hollebeek via Public <[email protected]> > wrote: > > > > Adopting the existing NSG by reference is exactly what I think the S/MIME > group should do. > > > > We should keep them the same and in sync across all WGs whenever possible. > > > > -Tim > > > > To stave that off, I’d like to accelerate moving the NSG work to a > top-level Forum group and get it out of the Server Certificate group. The > only complication I see is that by moving it to a top-level group, we’d > have to resolve whether it becomes across-the-board mandatory, or something > that each WG can adopt as a requirement or not as they see fit. It sounds > like this is highlighting the need to accomplish that sooner rather than > later; for the time being, would it work for the nascent S/MIME WG to > simply adopt the existing NSG by reference? > > > > -- Jos > > > > -- > Jos Purvis ([email protected]) > .:|:.:|:. cisco systems | Cryptographic Services > PGP: 0xFD802FEE07D19105 | +1 919.991.9114 (desk) > > > > > > *From: *Public <[email protected]> on behalf of Tim Hollebeek > via Public <[email protected]> > *Reply-To: *Tim Hollebeek <[email protected]>, CA/Browser Forum > Public Discussion List <[email protected]> > *Date: *Friday, 18 May, 2018 at 10:12 > *To: *Ryan Sleevi <[email protected]> > *Cc: *CA/Browser Forum Public Discussion List <[email protected]> > *Subject: *Re: [cabfpub] For Discussion: S/MIME Working Group Charter > > > > I’m interested in hearing feedback from the entire forum about what we can > pass. > > > > I’m less interested in rehashing old debates and holding this charter > hostage to them. > > > > The idea that NetSec is a set of cross-cutting requirements that applies > to all working groups has been mentioned many times and has never been > controversial, so I’m not sure how it morphed into a fundamental objection. > > > > -Tim > > > > *From:* Ryan Sleevi [mailto:[email protected] <[email protected]>] > *Sent:* Friday, May 18, 2018 10:06 AM > *To:* Tim Hollebeek <[email protected]> > *Cc:* CA/Browser Forum Public Discussion List <[email protected]>; > Dimitris Zacharopoulos <[email protected]> > *Subject:* Re: [cabfpub] For Discussion: S/MIME Working Group Charter > > > > Tim, > > > > I'm not clear - are you saying that you have no intention of removing the > proposal for a separate Network Security document from the S/MIME charter? > This is a real and fundamental objection, and I hope I've articulated why > it's problematic in a charter, and further, problematic in scope of > activities. I'm hoping you can clearly articulate the value, concretely > demonstrating why this is an immediate and cross-cutting problem to be > solved (and at the potential of conflict with other bits). Your proposal - > for example, to split NetSec into a separate CWG - demonstrates how and why > it's explicitly unnecessary to include in a draft charter. > > > > If you're not open to suggestions, then it seems the only alternative is > to provide a counter-charter proposal, and have a run-off, and that seems > like a very silly thing to do, when there's a real opportunity to > collaborate here, and that you seem to be outright rejecting without > justification. > > > > With respect to the notion of EV for S/MIME, I again reiterate that it's > wholly unnecessary to incorporate within the charter. Beyond being a > clearly marketing concept - in which it tries to distinguish itself from > the existing space - it's something that as a scope of work that, if there > is demonstrable value in such levels of validation, it can be incorporated > within a BRs. If you can't get a BRs you don't believe is secure for > purpose, then you're explicitly stating in the goal of WG is to fail in the > mission. Conversely, if you get a BRs that are, then you don't necessarily > need an "extended" version. > > > > My take away from these responses is that you're not actually interested > in feedback, as I'm trying to give clear and actionable explanations and > rationale for these positions. I can understand if you disagree, but is > there an opportunity here to collaborate on a sensible baseline, and to > address this feedback, or are you setting out a charter that seeks to > outright reject concerns that could help us find productive solutions, > quicker? > > > > On Fri, May 18, 2018 at 9:25 AM, Tim Hollebeek <[email protected]> > wrote: > > I agree mixing ClientAuth and S/MIME is a bad idea. > > > > NetSec is needed by all WGs. It’s not getting removed. Hopefully all WGs > will try to to keep their versions and effective dates in sync, to prevent > audit pains. As we’ve discussed several times, the NetSec legacy WG is > probably going to convert itself into a top level WG. It will the approve > documents that can be incorporated by other WGs by reference. Or just used > in conjunction with other WG products. > > > > Identity and validation is another important cross-cutting concern. It > isn’t a “pet marketing product”. > > > > -Tim > > > > *From:* Public [mailto:[email protected]] *On Behalf Of* Ryan > Sleevi via Public > *Sent:* Friday, May 18, 2018 9:18 AM > *To:* Dimitris Zacharopoulos <[email protected]>; CA/Browser Forum Public > Discussion List <[email protected]> > *Subject:* Re: [cabfpub] For Discussion: S/MIME Working Group Charter > > > > > > > > On Fri, May 18, 2018 at 12:57 AM, Dimitris Zacharopoulos via Public < > [email protected]> wrote: > > > > On 18/5/2018 2:51 πμ, Ryan Sleevi via Public wrote: > > I don't think it's a cross-EKU situation, though, but I'm glad we're in > agreement. > > > > An email server certificate is an id-kp-serverAuth EKU. That's already > covered by another WG > > > I sincerely hope that id-kp-clientAuth EKU will also be covered by this WG > since there will be common validation requirements for Subject information, > as with S/MIME. It seems too much overhead to spawn an entirely different > WG to deal just with clientAuth. > > If people agree, how about using the name "Client and S/MIME Certificate > WG" which seems aligned with the "Server Certificate WG"? > > > > As I've mentioned several times, it would be good to actually focus on a > constrained, defined problem, before you proverbially try to boil the ocean. > > > > It is not obvious that there will be common validation requirements, > because the id-kp-clientAuth situation has a vast dimension of possible > uses and spectrum. It's not actually reflective of the deployed reality > that the validation requirements are the same. It also is based on an > entirely separate notion of identity. > > > > So no, I don't agree, because they really are substantially different in > deployed reality - and an S/MIME WG is, in itself, a sizable undertaking > just to get S/MIME BRs, due to the broad spectrum of client capabilities > and CA past-practices - and the lifetime of extant certificates that > presents unique challenges to defining a sensible and realistic profile. > > > > A good charter - one that leads to productive engagement from a broad set > of participants while actually delivering meaningful improvements - is one > that keeps itself narrowly focused on the task at hand, produces results, > and then looks to recharter based on the things you knew were out there, > but agreed not to discuss until you actually completed the work. That > allows you to keep momentum, focus, and participation. Just look at the > challenges each of our (legacy) WG has faced with a broad remit, in that > the set of topics has made it difficult both to engage participation of the > broader Forum and to actually make forward progress, because it's > constantly having to deal with 'all these things' or trying to do 'all > these things'. > > > > When we see narrowly focused ballots and efforts that try to solve a > specific set of problems, then we make progress. The validation WG's effort > at 3.2.2.4 is a prime example of that - a prolonged effort that directly > benefited from being focused on that problem, and ruling some things (like > 3.2.2.5) out of scope of the discussion in order to make progress on the > narrow set. > > > > The same too is in the charter. Let's not try to encompass pet marketing > projects (EV for S/MIME), "things we might need but we don't know why" > (network security), or "things that are kinda related, but only in some > domains" (id-kp-clientAuth). Let's focus on the problem at hand - S/MIME > authentication - keeping the WG scoped narrowly and on task, and deliver > something that can help users have faith in the Web PKI to deliver tangible > benefits in that space, rather than the reality we have today. > > > > _______________________________________________ > Public mailing list > [email protected] > https://cabforum.org/mailman/listinfo/public > <https://clicktime.symantec.com/a/1/7onNLvmO9GUfgZ9GYsp8Vwaj_-r4OiPT9Z1o-F2DMgI=?d=lfaBq53v3yynj2JmaL82EvCVGPrITIM7kXUpp1q5kvRKGBn7zgzPaYIzFiv2KnUnnO97V8PMPA3b1d3EWqwEEZlB1V-sFdlkpepytiN_eYT-EQGI14RAQOqGfv9cuoflntSs9UvwvcTP3H1RSwhGWHkXzjZAloFEhj6lhVOgVbKk2QIh1rhagl06jOeBNqt_yXemgQn2CYA9YqmbUi3X_c45ZqJPNfG13nTQly5wKddYk8yw_zhDEgoOaNIxeoE5pL0zg4UdRmCNsdWcNSD7jvXb4I69Y7Yl07DiIuEhWF5vEte6N7DkxgQf-ITFuQSGPk6WIoYmhO4qfkiwdVE9RcyinfKkgg-o5vRO8efuUjaFDGo71dJJ0LipT_I39wEpjQbVq1Fzbrq4hubHSImqDcAyudk8pkAk6Cd2&u=https%3A%2F%2Fcabforum.org%2Fmailman%2Flistinfo%2Fpublic> > > >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
