<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";}
span.hoenzb
        {mso-style-name:hoenzb;}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;}
span.EmailStyle20
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<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.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></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? 
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Jeremy<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></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:sleevi@google.com]
<br>
<b>Sent:</b> Thursday, November 13, 2014 2:03 PM<br>
<b>To:</b> Jeremy Rowley<br>
<b>Cc:</b> CABFPub<br>
<b>Subject:</b> Re: [cabfpub] (Eventually) requiring id-kpServerAuth for all certs in the chain?<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></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.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></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?<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, Nov 13, 2014 at 12:59 PM, Jeremy.Rowley <<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>> wrote:<o:p></o:p></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 class="hoenzb">Jeremy</span></span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 11/13/2014 1:45 PM, Ryan Sleevi wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Jeremy, <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></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)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></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.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">So I'm not sure I fully understand your concern.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, Nov 13, 2014 at 12:40 PM, Jeremy.Rowley <<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>> wrote:<o:p></o:p></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.
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal">On 11/5/2014 2:31 PM, Brian Smith wrote:<o:p></o:p></p>
</div>
</div>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Gerv,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal">Gervase Markham <<a href="mailto:gerv@mozilla.org" target="_blank">gerv@mozilla.org</a>> wrote:<o:p></o:p></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.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></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?<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Cheers,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Brian<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
</div>
</div>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Public mailing list<o:p></o:p></pre>
<pre><a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><o:p></o:p></pre>
<pre><a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><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><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>