<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">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.<br>
<br>
<br>
On 11/13/2014 10:40 PM, Jeremy.Rowley wrote:<br>
</div>
<blockquote cite="mid:54651740.40504@digicert.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Doesn't all this ignore 5280's recommendation that "In general,
this extension will appear only in end entity certificates"?
Ignoring this might put browsers at odds with other industry
groups also using PKI.<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 11/5/2014 2:31 PM, Brian Smith
wrote:<br>
</div>
<blockquote
cite="mid:CAFewVt4zdftNJmMc6PFSNK77-2P7riwscmqkHWhcTob8-qD76w@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">Gerv,</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">
<div>Please note that Ryan and I appear to be suggesting
exactly the same thing. And, note that what I'm
suggesting here is exactly the same argument I made for
interpreting EKU in end-entity certificates earlier this
year or last year: a lack of EKU is equivalent to
"anyExtendedKeyUsage". This is what all (AFAICT)
certificate verification code does today.</div>
<div><br>
</div>
</div>
<div class="gmail_quote">Gervase Markham <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:gerv@mozilla.org"
target="_blank">gerv@mozilla.org</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"><span
class="">> However, I'm assuming that for the CAs
for which the BRs apply, it is<br>
> already the case that all or most of their
intermediates conform to the<br>
> BRs.<br>
<br>
</span>I would hope so. But is it programmatically
detectable that they do? If<br>
so, how? "Publicly audited" is not a determinable
characteristic of an<br>
intermediate.<br>
</blockquote>
<div><br>
</div>
<div>Your proposal has the same issue. In both proposals,
just by looking at the certificate chain, you can tell
whether the intermediate is required to conform to the
BRs or not. The only difference is that the way Ryan and
I are suggesting already matches what Chrome (on
Windows, at lesat), IE, and Firefox are already doing,
whereas you are proposing that all browsers eventually
(5-10 years from now?) be changed to do something new,
without any protection for users until then.</div>
<div><br>
</div>
<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">Also,
your proposal 1) requires a re-issue of intermediates
for all<br>
private PKIs, right? Because they all need to have EKUs
in them?<br>
</blockquote>
<div><br>
</div>
<div>If a CA certificate chains to a root for which the
BRs apply, and that sub-CA doesn't want to be held to
the BRs (ostensibly because they don't intend to issue
SSL certificates), then they would need to have their
sub-CA cert re-issued (and the old one revoked) with an
EKU extension that does not include id-kp-serverAuth or
anyExtendedKeyUsage, unless their certificate already
has such an EKU. That is the only situation in which
re-issuance would be necessary.</div>
<div><br>
</div>
<div>If private CAs don't issue SSL certificates, then it
would be a good idea to replace their CA certificates
with ones that contain an EKU that doesn't have
id-kp-serverAuth or anyExtendedKeyUsage, to follow the
principle of least privilege. But, they wouldn't be
required to make any change, because the BRs don't apply
to them, assuming that they don't chain to a trusted
root. If they do chain to a trusted root then they're
not private and the above paragraph applies.</div>
<div><br>
</div>
<div>Cheers,<br>
</div>
<div>Brian</div>
<div><br>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Public mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<br>
<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>