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

[Ryan Sleevi]

The proposed path forward in the past was to split NSG to a separate CWG,
and ensuring that the scope is generally applicable.

The ideal outcome is that other CWGs would simply adopt those requirements
as-is, and that they'd reflect an appropriate set for all WGs. Members
within a (different) CWG that wished to make proposals could join the
NetSec WG and make those contributions under the scope of the policies
there.

Less ideal, but imaginable, would be a CWG that makes redline requirements
to the NSGs - whether additive or subtractive - as applicable only to the
scope of their WG. The challenge with this is that the IPR covers the
document produced, and since the NSGs were produced within such a CWG,
members of this 'downstream' CWG can't be sure that the sum intersecting
total of their modifications is IP-clean, because there may be Essential
Claims governing the intersection of the NSG+modifications that don't
govern the NSG or the modifications individually (and thus escape IP
disclosure for either WG)

I think that, given the nature of our work, the 'ideal outcome' is both
realistic (from a workmode perspective) and preferable for both auditors
and CAs. CWGs that are 'downstream' (such as server cert or S/MIME) can
merely indicate that compliance with the NSGs is expected as part of their
respective documents (the Server Cert BRs or the S/MIME BRs), without
modification or caveat.

If two CWGs have conflicting requirements, the NSG would ideally adopt the
lowest common denominator in the document. If the two CWGs felt that their
requirements were essential to their respective work, they could do the
redlining by making additions to the NSG (that is, specifically, "For
Server Cert BRs, we require compliance to the Net Sec BRs, along with
Server Cert Net Sec Requirements 1, 2, 3" and "For S/MIME BRs, we require
compliance to the Net Sec BRs, along with S/MIME requirements A, B, C",
where no system can comply with both 1/2/3 and A/B/C, as they're mutually
exclusive), but with the recognition that such an adoption fundamentally
means that CAs will have to operating their Server Cert PKI as distinct and
disparate from their S/MIME PKI.

None of these are the end of the world. All resolve the problem.

Of course, this is not blocking towards the formation of an S/MIME WG. An
S/MIME WG can charter itself with just a focus on the BRs, and leave this
as a separable problem to be addressed. There's no fundamental or inherent
dependency chain that suggests we need to resolve both simultaneously to
make forward progress, which is precisely why I'm suggesting we strike it
from the charter, and allow it to be a separate problem to independently
explore and possibly address.

On Fri, May 18, 2018 at 10:34 AM, Jos Purvis (jopurvis) <jopurvis at cisco.com>
wrote:

> I very much agree that all CA requirements need a Network Security
> element. I do worry (and I think this is part of Ryan’s objection too?)
> about the possibility of fragmentation of requirements that may create
> either mutually exclusive requirements or confusion over what applies. As
> an example, imagine what happens when an S/MIME CA and a Server-Cert CA are
> hanging from the same root—whose NSG governs the root?
>
>
>
> 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]
> *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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20180518/b8c5b9ee/attachment-0001.html>