<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    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).<br>
    <br>
    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.<br>
    <br>
    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. <br>
    <br>
    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 :)<br>
    <br>
    <br>
    <br>
    Dimitris.<br>
    <br>
    <div class="moz-cite-prefix">On 24/5/2018 2:34 πμ, Moudrick M.
      Dadashov wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:77fbe7ff-d4e4-96d8-3c86-b548243f2980@ssc.lt">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <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"
                moz-do-not-send="true">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" moz-do-not-send="true"><jimmy@it.auth.gr></a>;
              CA/Browser Forum Public Discussion List <a
                class="moz-txt-link-rfc2396E"
                href="mailto:public@cabforum.org" moz-do-not-send="true"><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" moz-do-not-send="true">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public" moz-do-not-send="true">https://cabforum.org/mailman/listinfo/public</a>
</pre>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>