<div dir="ltr">That's the fundamental difference between Gerv's proposal and mine.<div><br></div><div>My proposal is that all of the certs capable must be audited, with capable be defined as either the presence of (id-kp-serverAuth, anyEKU) in the intermediate OR the absence of ALL EKUs in the intermediate. If it's capable, it MUST be audited to the BRs.</div><div><br></div><div>If you thus wish to exclude such an intermediate from the scope of a BR audit (for example, because you intend to use it with some other scheme), then you need to change your hierarchy. However, if you're not such a CA running multiple schemes, then no action is required, and all the intermediates stay useful.</div><div><br></div><div>Then we can independently discuss any changes, but it solves the near-term ambiguity.</div><div><br></div><div>Gerv's proposal requires more drastic actions, and thus will naturally take quite some time to phase in.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 13, 2014 at 1:01 PM, Moudrick M. Dadashov <span dir="ltr"><<a href="mailto:md@ssc.lt" target="_blank">md@ssc.lt</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" text="#000000">
    <div>Thanks, Ryan, I see the point.<br>
      Is there a non extreme approach here that preserves those valuable
      libraries and doesn't kill those intermediates that have been in
      use for years? Could it a transitional time frame after which we
      have a single, widely supported solution?<br>
      <br>
      Thanks,<br>
      M.D.    <br><div><div class="h5">
      <br>
      <br>
      On 11/13/2014 10:53 PM, Ryan Sleevi wrote:<br>
    </div></div></div><div><div class="h5">
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Thu, Nov 13, 2014 at 12:51 PM,
            Moudrick M. Dadashov <span dir="ltr"><<a href="mailto:md@ssc.lt" target="_blank">md@ssc.lt</a>></span> wrote:<br>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000">
                <div>It certainly does. I understand folks looking for a
                  programmatic discovery of cert types, but still
                  curious why EKU is more appropriate for this than any
                  other predefined field that raises no conflict with
                  standards.<br>
                  <br>
                  Thanks,<br>
                  M.D.
                  <div>
                    <div><br>
                    </div>
                  </div>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>Because it's widely implemented in a variety of
              libraries and provides immediate security benefits for
              clients, and immediate clarifications for CAs about in
              scope vs out of scope, and doesn't conflict with any of
              the language in RFC 5280 - which, while was accurate at
              the time it was written ("In general, this doesn't appear
              in CA certs"), is NOT a prohibition against it, just an
              observation.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </div></div></div>

</blockquote></div><br></div>