<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <font face="Cambria">All three (clentAuth and S/MIME) use scenarios
      are </font><font face="Cambria">essentially different.<br>
      <br>
      Validation requirements for issuing signing/encryption
      certificates are mostly similar, clientAuth (as we understand it
      under eIDAS*) is different.<br>
      <br>
      Thanks,<br>
      M.D.  <br>
      <br>
      * Article 3<br>
      (5) ‘<i><b>authentication</b>’ 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</i>.<br>
      <br>
      (1) ‘<i><b>electronic identification</b>’ 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</i>.<br>
      <br>
      (2) ‘<i><b>electronic identification means</b>’ means a material
        and/or immaterial unit containing person identification data and
        which is used for authentication for an online service</i>.<br>
      <br>
       </font><br>
    <br>
    <div class="moz-cite-prefix">On 5/24/2018 12:16 AM, Brown, Wendy
      (10421) via Public wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:BN6PR03MB304450C8EAF8EB178305B171EE6B0@BN6PR03MB3044.namprd03.prod.outlook.com">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.gmail-
        {mso-style-name:gmail-;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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..<o:p></o:p></span></p>
        <p class="MsoNormal"><a name="_MailEndCompose"
            moz-do-not-send="true"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></a></p>
        <p class="MsoNormal"><b><span
              style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">
            Public [<a class="moz-txt-link-freetext" href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>]
            <b>On Behalf Of </b>Ryan Sleevi via Public<br>
            <b>Sent:</b> Friday, May 18, 2018 9:18 AM<br>
            <b>To:</b> Dimitris Zacharopoulos <a class="moz-txt-link-rfc2396E" href="mailto:jimmy@it.auth.gr"><jimmy@it.auth.gr></a>;
            CA/Browser Forum Public Discussion List
            <a class="moz-txt-link-rfc2396E" href="mailto:public@cabforum.org"><public@cabforum.org></a><br>
            <b>Subject:</b> Re: [cabfpub] For Discussion: S/MIME Working
            Group Charter<o:p></o:p></span></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <div>
          <p class="MsoNormal"><o:p> </o:p></p>
          <div>
            <p class="MsoNormal"><o:p> </o:p></p>
            <div>
              <p class="MsoNormal">On Fri, May 18, 2018 at 12:57 AM,
                Dimitris Zacharopoulos via Public <<a
                  href="mailto:public@cabforum.org" target="_blank"
                  moz-do-not-send="true">public@cabforum.org</a>>
                wrote:<o:p></o:p></p>
              <blockquote style="border:none;border-left:solid #CCCCCC
                1.0pt;padding:0in 0in 0in
                6.0pt;margin-left:4.8pt;margin-right:0in">
                <div>
                  <p class="MsoNormal" style="margin-bottom:12.0pt"><span
                      class="gmail-"><o:p> </o:p></span></p>
                  <div>
                    <p class="MsoNormal">On 18/5/2018 2:51 πμ, Ryan
                      Sleevi via Public wrote:<o:p></o:p></p>
                  </div>
                  <blockquote
                    style="margin-top:5.0pt;margin-bottom:5.0pt">
                    <div>
                      <p class="MsoNormal">I don't think it's a
                        cross-EKU situation, though, but I'm glad we're
                        in agreement.
                        <o:p></o:p></p>
                      <div>
                        <p class="MsoNormal"><o:p> </o:p></p>
                      </div>
                      <div>
                        <p class="MsoNormal">An email server certificate
                          is an id-kp-serverAuth EKU. That's already
                          covered by another WG<o:p></o:p></p>
                      </div>
                    </div>
                  </blockquote>
                  <p class="MsoNormal"><br>
                    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.<br>
                    <br>
                    If people agree, how about using the name "Client
                    and S/MIME Certificate WG" which seems aligned with
                    the "Server Certificate WG"?<o:p></o:p></p>
                </div>
              </blockquote>
              <div>
                <p class="MsoNormal"><o:p> </o:p></p>
              </div>
              <div>
                <p class="MsoNormal">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.<o:p></o:p></p>
              </div>
              <div>
                <p class="MsoNormal"><o:p> </o:p></p>
              </div>
              <div>
                <p class="MsoNormal">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.<o:p></o:p></p>
              </div>
              <div>
                <p class="MsoNormal"><o:p> </o:p></p>
              </div>
              <div>
                <p class="MsoNormal">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.<o:p></o:p></p>
              </div>
              <div>
                <p class="MsoNormal"><o:p> </o:p></p>
              </div>
              <div>
                <p class="MsoNormal">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'.<o:p></o:p></p>
              </div>
              <div>
                <p class="MsoNormal"><o:p> </o:p></p>
              </div>
              <div>
                <p class="MsoNormal">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.<o:p></o:p></p>
              </div>
              <div>
                <p class="MsoNormal"><o:p> </o:p></p>
              </div>
              <div>
                <p class="MsoNormal">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.<o:p></o:p></p>
              </div>
            </div>
          </div>
        </div>
      </div>
      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.
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>