<div dir="ltr">If these groups are requiring that it MUST NOT appear in intermediates, then they're defining a profile atop RFC 5280, right? So it's not that it's an RFC 5280 issue, but a broader issue with whatever other specification.<div><br></div><div>If it were that some group required EE certs MUST be RSA 1024-bit, or MUST use SHA-1, would we have the same concern? I recall some for the former (ironically, in the payment industry, which is all sorts of depressing), less so for the latter, but in either case, this seems to highlight a fundamental issue with CAs trying to use the same root to be audited to multiple standards - at some point, you must be prepared for the standards to diverge.</div><div><br></div><div>There are plenty of ways to mitigate those risks (as has been discussed in the past), but is it a Forum issue or a CA-using-the-same-root-for-different-things issue?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 13, 2014 at 12:59 PM, Jeremy.Rowley <span dir="ltr"><<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</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">
I realize it's not normative and it's not really a concern for us -
more of an observation that requiring an EKU in intermediates is
opposite of the text in the RFC. The issue is not that we'd break
those other groups but that we'd force their intermediates to comply
with the BRs, which might not be possible for some groups.<span class="HOEnZb"><font color="#888888"><br>
<br>
Jeremy</font></span><div><div class="h5"><br>
<br>
<div>On 11/13/2014 1:45 PM, Ryan Sleevi
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Jeremy,
<div><br>
</div>
<div>that language is hardly normative, nor are there normative
restrictions on it, nor would it adversely affect the
algorithm of RFC 5280 Section 6 (and indeed, if someone was
enforcing that CAs not have the EKU, they'd be violating
Section 6.1 para3)</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">While
the algorithm could be extended to include checks for<br>
conformance to the profiles in Sections 4 and 5, this profile<br>
RECOMMENDS against including such checks.</blockquote>
<div><br>
</div>
<div>So I'm not sure I fully understand your concern.</div>
<div> </div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Nov 13, 2014 at 12:40 PM,
Jeremy.Rowley <span dir="ltr"><<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</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"> 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.
<div>
<div><br>
<br>
<br>
<br>
<div>On 11/5/2014 2:31 PM, Brian Smith wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div>
<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 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>>
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></fieldset>
<br>
</div>
</div>
<span>
<pre>_______________________________________________
Public mailing list
<a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</span></blockquote>
<br>
</div>
<br>
_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>