[cabfpub] For Discussion: S/MIME Working Group Charter

[Ryan Sleevi]

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 <tim.hollebeek at digicert.com>
wrote:

> That is accurate.
>
>
>
> -Tim
>
>
>
> *From:* Peter Bowen [mailto:pzb at amzn.com]
> *Sent:* Friday, May 18, 2018 11:26 AM
> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>; CA/Browser Forum Public
> Discussion List <public at cabforum.org>
> *Cc:* Jos Purvis (jopurvis) <jopurvis at cisco.com>; Ryan Sleevi <
> sleevi at google.com>
>
> *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 <public at cabforum.org>
> 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 (jopurvis at cisco.com)
> .:|:.:|:. cisco systems  | Cryptographic Services
> PGP: 0xFD802FEE07D19105  | +1 919.991.9114 (desk)
>
>
>
>
>
> *From: *Public <public-bounces at cabforum.org> on behalf of Tim Hollebeek
> via Public <public at cabforum.org>
> *Reply-To: *Tim Hollebeek <tim.hollebeek at digicert.com>, CA/Browser Forum
> Public Discussion List <public at cabforum.org>
> *Date: *Friday, 18 May, 2018 at 10:12
> *To: *Ryan Sleevi <sleevi at google.com>
> *Cc: *CA/Browser Forum Public Discussion List <public at cabforum.org>
> *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:sleevi at google.com <sleevi at google.com>]
> *Sent:* Friday, May 18, 2018 10:06 AM
> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>
> *Cc:* CA/Browser Forum Public Discussion List <public at cabforum.org>;
> Dimitris Zacharopoulos <jimmy at it.auth.gr>
> *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 <tim.hollebeek at digicert.com>
> 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:public-bounces at cabforum.org] *On Behalf Of* Ryan
> Sleevi via Public
> *Sent:* Friday, May 18, 2018 9:18 AM
> *To:* Dimitris Zacharopoulos <jimmy at it.auth.gr>; CA/Browser Forum Public
> Discussion List <public at cabforum.org>
> *Subject:* Re: [cabfpub] For Discussion: S/MIME Working Group Charter
>
>
>
>
>
>
>
> On Fri, May 18, 2018 at 12:57 AM, Dimitris Zacharopoulos via Public <
> public at cabforum.org> 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
> Public at cabforum.org
> 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>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20180518/9d424e95/attachment-0001.html>