<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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=windows-1252">
<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 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>