<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Ok, sounds like what you are offering
perfectly works for ETSI TS 102 042 audited CAs - all SSL capable
intermediates pass audit so nobody cares what their EKUs were,
right. If this is what you mean, I'm fine with it.<br>
<br>
Thanks,<br>
M.D. <br>
<br>
On 11/13/2014 11:06 PM, Ryan Sleevi wrote:<br>
</div>
<blockquote
cite="mid:CACvaWvZcLPSOqnRXL7mBwPNCv-c4_zUVxTknkJnoZtnMvttZwA@mail.gmail.com"
type="cite">
<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
moz-do-not-send="true" 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 moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>