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

Ryan Sleevi sleevi at google.com
Thu May 24 14:39:00 UTC 2018


I don't disagree with that either :) Sorry if that wasn't clearer - I meant
the basic foundation of how you validate an e-mail address is going to be
key. Whether that's by validating the domain holder and allowing them to
self-attest to the correctness of every email (much like we allow them to
do so with subdomains beneath an ADN) or whether that's validating directly
to the email address, at the core, we need to make sure that the rfc822Name
within an S/MIME certificate is sufficiently validated.

That's why my concrete encouragement was to start with S/MIME BRs as the
sole deliverable. Work through the operational and issuance profile, work
through the core validation mechanisms, and table discussions that would
otherwise detract from that. Once we've got a common and understood
baseline, then it can be explored whether there are more rigorous forms
that are both possible and useful.

On Thu, May 24, 2018 at 10:32 AM, Tim Hollebeek <tim.hollebeek at digicert.com>
wrote:

> Some organizations, including Mozilla, think domain validation is also a
> valid email validation use case.  This is especially important for
> enterprises.
>
>
>
> But I agree with the rest.
>
>
>
> -Tim
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi at google.com]
> *Sent:* Thursday, May 24, 2018 10:18 AM
> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>
> *Cc:* Dimitris Zacharopoulos <jimmy at it.auth.gr>; CA/Browser Forum Public
> Discussion List <public at cabforum.org>; Moudrick M. Dadashov <md at ssc.lt>;
> Brown, Wendy (10421) <wendy.brown at protiviti.com>
>
> *Subject:* Re: [cabfpub] For Discussion: S/MIME Working Group Charter
>
>
>
> Right, to be clear, I'm opposed to treating clientAuth with S/MIME.
>
>
>
> I understand that, in some spaces, S/MIME identity is tied to legal
> identity. But S/MIME also has the potential of great value being tied to
> simply e-mail identity - or to organizational identity. If you will, this
> is the distinction between DV, IV, OV, and EV.
>
>
>
> My view is that just like DV is the basis for all other forms of
> serverAuth certificates, e-mail validation is the core to S/MIME. Getting
> that correct prevents any future improvements - that is, you cannot build a
> legal identity of S/MIME without first establishing and validating the
> e-mail.
>
>
>
> Thus, a good charter should start solely with S/MIME, and solely with
> e-mail validation.
>
>
>
> If that is successful, as a Baseline, then folks can and should be free to
> safely explore building on that foundation for other forms - for example,
> if organizational validation is appropriate, or in the case of eIDAS, if
> individual validation.
>
>
>
> clientAuth is orthogonal in this, in that it can have many different forms
> of asserted identities (such as a SAN of a dNSName or a SAN of an
> rfc822Name) or no technical identity. Its usage, like code-signing, is
> going to vary on the consumer - and thus general rules are NOT applicable,
> but instead is going to need to be evaluated for each and every application
> context. While eIDAS considers that notion, it's doing so on flawed
> technical grounds (an entirely separate issue), but I highlight it because
> the eIDAS notion of clientAuth is vastly different than, say, the XMPP
> notion of clientAuth, even though they use the same key policy.
>
>
>
> The solution to all of these challenges is not to try to solve them all at
> once, it's to start and make sure there is a common base certificate
> profile, and a core understanding of the validation of the primary
> identifier appropriate for S/MIME (the email address), and then build more
> expressive, additive systems on top of that, if and as there is
> demonstrated need and consumption. Just because something "could" be done
> doesn't necessarily mean it should, and just because some PKIs (like eIDAS)
> introduce some ideas doesn't mean they're good - but without a firm
> footing, and without a charter to explicitly focus on solely that topic,
> not much progress can or will be made.
>
>
>
> On Thu, May 24, 2018 at 8:57 AM, Tim Hollebeek <tim.hollebeek at digicert.com>
> wrote:
>
> Yeah, I want something focused.  There are lots of different clientAuth
> use cases, not just individual identity.  clientAuth only looks like
> emailProtection if you’re limiting yourself to the use cases where there’s
> strong overlap.  Which makes the argument that they are similar essentially
> a tautology.  Remember, clientAuth can also be mutual authentication for
> web services.  That looks nothing like emailProtection.
>
>
>
> So let’s get email on a firm footing first, and if the section of the
> clientAuth BRs for individuals is heavily based on the emailProtection BRs,
> that just saves us work in the future.
>
>
>
> -Tim
>
>
>
> *From:* Public [mailto:public-bounces at cabforum.org] *On Behalf Of *Dimitris
> Zacharopoulos via Public
> *Sent:* Thursday, May 24, 2018 1:05 AM
> *To:* Moudrick M. Dadashov <md at ssc.lt>; Brown, Wendy (10421) <
> wendy.brown at protiviti.com>; CA/Browser Forum Public Discussion List <
> public at cabforum.org>; Ryan Sleevi <sleevi at google.com>
>
>
> *Subject:* Re: [cabfpub] For Discussion: S/MIME Working Group Charter
>
>
>
>
> Moudrick, I don't think we are describing just use scenarios. This is
> about subject validation and as you are very well familiar, eIDAS is also
> setting requirements for how you validate natural persons and legal
> entities. Then, you can use this validated information for different trust
> services (authenticate, sign, encrypt, etc).
>
> We already have identity validation requirements for the server
> certificate Working Group, described in DV/OV/EV Policies for certificates
> with id-kp-serverAuth EKU. Why shouldn't we include identity validation
> requirements for this new Working Group for certificates with
> id-kp-clientAuth and id-kp-emailProtection EKU? The overlap in subject
> validation requirements between these two cases is pretty obvious.
>
> Even though I'd like the clientAuth to be included in the WG's initial
> charter, I understand Ryan's argument for gradually building a standard
> with minimum expectations at the beginning (thus limiting the scope for
> S/MIME only) and expand the scope later.
>
> So, until then, the clientAuth Certificates will remain kind-of
> "unregulated" by lacking a policy standard. I suppose we will have to live
> with that :)
>
>
>
> Dimitris.
>
> On 24/5/2018 2:34 πμ, Moudrick M. Dadashov wrote:
>
> All three (clentAuth and S/MIME) use scenarios are essentially different.
>
> Validation requirements for issuing signing/encryption certificates are
> mostly similar, clientAuth (as we understand it under eIDAS*) is different.
>
> Thanks,
> M.D.
>
> * Article 3
> (5) ‘*authentication**’ means an electronic process that enables the
> electronic identification of a natural or legal person, or the origin and
> integrity of data in electronic form to be confirmed*.
>
> (1) ‘*electronic identification**’ means the process of using person
> identification data in electronic form uniquely representing either a
> natural or legal person, or a natural person representing a legal person*.
>
> (2) ‘*electronic identification means**’ means a material and/or
> immaterial unit containing person identification data and which is used for
> authentication for an online service*.
>
>
>
> On 5/24/2018 12:16 AM, Brown, Wendy (10421) via Public wrote:
>
> I second the opinion that  clientAuth and S/Mime are likely to have a
> great overlap in validation requirements at least when issuing to persons
> and PKIs may want to issue both types of certs from the same CA if they are
> for the same validated individual..
>
>
>
> *From:* Public [mailto:public-bounces at cabforum.org
> <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> <jimmy at it.auth.gr>;
> CA/Browser Forum Public Discussion List <public at cabforum.org>
> <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.
>
> NOTICE: Protiviti is a global consulting and internal audit firm composed
> of experts specializing in risk and advisory services. Protiviti is not
> licensed or registered as a public accounting firm and does not issue
> opinions on financial statements or offer attestation services. This
> electronic mail message is intended exclusively for the individual or
> entity to which it is addressed. This message, together with any
> attachment, may contain confidential and privileged information. Any views,
> opinions or conclusions expressed in this message are those of the
> individual sender and do not necessarily reflect the views of Protiviti
> Inc. or its affiliates. Any unauthorized review, use, printing, copying,
> retention, disclosure or distribution is strictly prohibited. If you have
> received this message in error, please immediately advise the sender by
> reply email message to the sender and delete all copies of this message.
> Thank you.
>
> _______________________________________________
>
> Public mailing list
>
> Public at cabforum.org
>
> https://cabforum.org/mailman/listinfo/public <https://clicktime.symantec.com/a/1/58b5lg-6qgJoiyMkuFyyjihEGUHAEye9DPRKzbfObTU=?d=8mgvcIa__SMpMRdOdO1qWcxXiKx9B8jzWMVa2uIlIWMvKWPFJg5PqissoC0faEZm0JLNJpuB-XiKhkLZe65-75a2W5qQuwsBma30V8Dulu3KXzTcES_XiIVyNkQ-597msxngSDFqzttf9473QFBumD6nABAjOqHoHWbWeUSIz4rbJXzFhZDAZnDowXjy-62yv1T_uV7QXGviotaVkpSrQZPBHWmuvzxTnR53mjKetqi-x8Rr4TrixNmJl2Ihc2z0r3SfgqRRNcFDSMka5DYYJsw66ZeDSlDw5NuqD6JuKw-nQvSWeSm29eQp5pieOFFY7aA3klzX5nFyNzj1S9QAfyv6XVu7FPyH01BPbVFcWEH5MT-swmz8niSggeq5hB-Xv1hb_NSb_VJeKXRmwx0FO15BtFlTvPx_w21FCIOf&u=https%3A%2F%2Fcabforum.org%2Fmailman%2Flistinfo%2Fpublic>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180524/c4520e5b/attachment-0003.html>


More information about the Public mailing list