<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I support it. If it can issue certs, it should be covered by the BR
audit. I'm still interested in seeing if there any communities that
would be negatively affected by this for any reason other than cost.<br>
<br>
Jeremy<br>
<br>
<div class="moz-cite-prefix">On 11/13/2014 2:13 PM, Ryan Sleevi
wrote:<br>
</div>
<blockquote
cite="mid:CACvaWvZ7nHEjvXSSJpcjCki1TChJ662uwuVF_4=1i=mtSZ04-g@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">Jeremy,
<div><br>
</div>
<div>If the extent of Gerv's proposal is that it has to
disappear off into a research group, what are your feelings
for my proposal, which is to clarify that it IS in scope for a
BR audit?</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Nov 13, 2014 at 1:10 PM, Jeremy
Rowley <span dir="ltr"><<a moz-do-not-send="true"
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 link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The
SHA-1/1024 bit issue is a good point. However, it’s
easier to impose new requirements on EE certs than
an intermediate, meaning I’d be more cautious in the
change. I’m in favor of the proposal, but a year
might be a little short if we’re dealing with
multiple standards bodies.
</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I’m
also not aware of which bodies this might affect. I
think we should ask the various groups and see if
any intermediate could not comply with both the BRs
and their policies. That way we have actual factual
basis for discussion rather than speculation. I’ll
reach out to my contacts and report back as soon as
possible. If others could do the same, it’d be
appreciated.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Moudrick
– you mentioned this is a concern? Do you know what
bodies this might create a problem for and why?
</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Jeremy</span></p>
<p class="MsoNormal"><a moz-do-not-send="true"
name="149aafe608844aa5__MailEndCompose"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></a></p>
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
Ryan Sleevi [mailto:<a moz-do-not-send="true"
href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>]
<br>
<b>Sent:</b> Thursday, November 13, 2014 2:03 PM<br>
<b>To:</b> Jeremy Rowley<br>
<b>Cc:</b> CABFPub<span class=""><br>
<b>Subject:</b> Re: [cabfpub] (Eventually)
requiring id-kpServerAuth for all certs in the
chain?</span></span></p>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">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.</p>
<div>
<div class="h5">
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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?</p>
</div>
</div>
</div>
</div>
<div>
<div class="h5">
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">On Thu, Nov 13, 2014 at
12:59 PM, Jeremy.Rowley <<a
moz-do-not-send="true"
href="mailto:jeremy.rowley@digicert.com"
target="_blank">jeremy.rowley@digicert.com</a>>
wrote:</p>
<div>
<p class="MsoNormal">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
style="color:#888888"><br>
<br>
<span>Jeremy</span></span></p>
<div>
<div>
<p class="MsoNormal"
style="margin-bottom:12.0pt"> </p>
<div>
<p class="MsoNormal">On 11/13/2014 1:45
PM, Ryan Sleevi wrote:</p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Jeremy, </p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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)</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<blockquote
style="border:none;border-left:solid
#cccccc 1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">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.</p>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">So I'm not sure
I fully understand your concern.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">On Thu, Nov 13,
2014 at 12:40 PM, Jeremy.Rowley
<<a moz-do-not-send="true"
href="mailto:jeremy.rowley@digicert.com"
target="_blank">jeremy.rowley@digicert.com</a>>
wrote:</p>
<div>
<p class="MsoNormal">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.
</p>
<div>
<div>
<p class="MsoNormal"
style="margin-bottom:12.0pt"><br>
<br>
<br>
</p>
<div>
<p class="MsoNormal">On
11/5/2014 2:31 PM, Brian
Smith wrote:</p>
</div>
</div>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Gerv,</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<div>
<p class="MsoNormal">Gervase
Markham <<a
moz-do-not-send="true"
href="mailto:gerv@mozilla.org" target="_blank">gerv@mozilla.org</a>>
wrote:</p>
<p class="MsoNormal">>
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>
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.</p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<blockquote
style="border:none;border-left:solid
#cccccc
1.0pt;padding:0in
0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">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?</p>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Cheers,</p>
</div>
<div>
<p class="MsoNormal">Brian</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"
style="margin-bottom:12.0pt"> </p>
</div>
</div>
<pre>_______________________________________________</pre>
<pre>Public mailing list</pre>
<pre><a moz-do-not-send="true" href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a></pre>
<pre><a moz-do-not-send="true" href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a></pre>
</blockquote>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal"
style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
Public mailing list<br>
<a moz-do-not-send="true"
href="mailto:Public@cabforum.org"
target="_blank">Public@cabforum.org</a><br>
<a moz-do-not-send="true"
href="https://cabforum.org/mailman/listinfo/public"
target="_blank">https://cabforum.org/mailman/listinfo/public</a></p>
</div>
<p class="MsoNormal"> </p>
</div>
</blockquote>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>