<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 18, 2018 at 12:57 AM, Dimitris Zacharopoulos via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF"><span class="gmail-">
    <br>
    <br>
    <div class="gmail-m_3231149072477110049moz-cite-prefix">On 18/5/2018 2:51 πμ, Ryan Sleevi via
      Public wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">I don't think it's a cross-EKU situation, though,
        but I'm glad we're in agreement.
        <div><br>
        </div>
        <div>An email server certificate is an id-kp-serverAuth EKU.
          That's already covered by another WG</div>
      </div>
    </blockquote>
    <br></span>
    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"?</div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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'.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></div>