<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;}
/* 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;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{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">I think Ryan’s suggestion is best. If all intermediates capable of SSL issuance are BR audited, then there isn’t an issue. You still need to disclose their
existence in accordance with the Mozilla policy, but there won’t be a need to reissue the certs.
<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">Plus, all the groups I contacted responded that their intermediates are already compliant and wouldn’t have issues with a BR audit. I’d support moving forward
with Ryan’s proposal.<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"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Jeremy<o:p></o:p></span></a></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"><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""> me@chemalogo.com [mailto:me@chemalogo.com]
<b>On Behalf Of </b>Chema López González<br>
<b>Sent:</b> Wednesday, November 19, 2014 2:00 AM<br>
<b>To:</b> Ryan Sleevi<br>
<b>Cc:</b> Jeremy Rowley; 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">What if browser return to old times and starts not only to trust in Root CAs but also to include in tis programs (and certificate stores) intermediate CAs for different purposes. <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I thanks the consideration of Gerv proposing to "<span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">BRs should say that all non-root certs in a chain issued for SSL server use,
<b><u>which were issued after <date></u></b>, should have EKU id-kpServerAuth in them. Date would be, say, six months from now.</span>"<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Take into account that, for CA, reissuing and intermediate CA cert is very inconvinient. Not only browsers but a lot of other programs, VAs, Public Admin websites and so may trust in the new certificate, so thinking that there is only the
need to include your certificates in the browsers program is only seeing the tip of the iceberg.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Maybe it is a wrong impression but sometimes I have the feeling that when something has to change for the sake of securing the Internet, the main load of work goes to the CAs.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">BR,<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal"><span style="color:#888888">-- </span><o:p></o:p></p>
<div>
<p class="MsoNormal"><b><span style="color:#888888">Chema López</span></b><o:p></o:p></p>
<div>
<p class="MsoNormal"><b><span style="color:#999999">Gestor de Proyectos - Departamento Técnico</span></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b><span style="color:#999999">AC Firmaprofesional, S.A.</span></b><span style="color:#888888"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#999999">Edificio ESADECREAPOLIS - 1B13</span><span style="color:#888888"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#999999">08173 Sant Cugat del Vallès, Barcelona. </span><span style="color:#888888"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#999999">T. 934 774 245</span><span style="color:#888888"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#999999">M. 666 429 224</span><span style="color:#888888"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">2014-11-13 23:08 GMT+01:00 Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>>:<o:p></o:p></p>
<p><br>
On Nov 13, 2014 11:54 AM, "Jeremy.Rowley" <<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>> wrote:<br>
><br>
> Maybe not. I'm only aware of the Mozilla communities. I sent one a PM asking them to chime in if there is a problem for their community. They probably won't chime in but this gives awareness in what's going on.
<br>
><br>
> Where do you get that the items mentioned violate Mozilla's policy? Mozilla expressly excluded the auditor requirements from the BRs, don't have a policy for key ceremonies, and permit either CRLs or OCSP (while the BRs require both for intermediates).
No violation if you weren't intending to issue SSL.<br>
><br>
><o:p></o:p></p>
<p>I was merely pointing out that the Mozilla policy requires the entire hierarchy follow the Mozilla policy, and that any CA technically capable of issuing certs must meet the Mozilla policy, including explicitly being BR audited.<o:p></o:p></p>
<p>This differs from the BRs, which allow CAs significant leverage to carve out parts of their infrastructure as excluded from audits.<o:p></o:p></p>
<div>
<div>
<p>><br>
> On 11/13/2014 2:34 PM, Ryan Sleevi wrote:<br>
>><br>
>><br>
>> On Nov 13, 2014 11:28 AM, "Jeremy Rowley" <<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>> wrote:<br>
>> ><br>
>> > That page was updated in October 2014. I don’t think we can imply knowledge to all communities who might have existed before then. <br>
>> ><br>
>> > <br>
>><br>
>> Sure, but isn't that the point - Mozilla makes its decisions in the interest of its user community, and if you're forking the trust list from Mozilla (which is what it is), you should follow the fork.<br>
>><br>
>> Again, I don't think this is something relevant to the discussion at hand or the Forum at large. If it was, why aren't we talking about communities who MIGHT have forked authroots.ctl or copied the roots from the Security.keychain services?<br>
>><br>
>> If Mozilla requires all CAs in their program follow their policies, and if a CA can't follow Mozilla's policies (which currently go above and beyond the BRs), then that isn't a Forum issue - it is for Mozilla and those CAs to work out.<br>
>><br>
>> ><br>
>> > I also don’t think the audit itself is a concern. However, the requirements on key generation under Section 17.7 might not have been followed, the intermediate might not have CRLs or OCSP (depending on the community), and auditor qualifications might
be bigger problems.<br>
>> ><br>
>><br>
>> And then they're in violation of Mozilla's inclusion policies already. Which is a matter for Mozilla to take up, but suggests they're already in trouble independent of the Forum requiring the same.<br>
>><br>
>> > <br>
>> ><br>
>> > From: Ryan Sleevi [mailto:<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>]
<br>
>> > Sent: Thursday, November 13, 2014 2:18 PM<br>
>> > To: Jeremy Rowley<br>
>> > Cc: Moudrick M. Dadashov; CABFPub<br>
>> ><br>
>> > Subject: Re: [cabfpub] (Eventually) requiring id-kpServerAuth for all certs in the chain?<br>
>> ><br>
>> > <br>
>> ><br>
>> > <br>
>> ><br>
>> > On Thu, Nov 13, 2014 at 1:13 PM, Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>> wrote:<br>
>> ><br>
>> > One other thought is that a lot of groups use NSS as their basis for a trust store. Impairing all the communities relying on that trust store might negatively impact the usefulness of NSS, meaning the issue is not as simple as using a single CA for multiple
purposes v. creating forum rules.<br>
>> ><br>
>> > <br>
>> ><br>
>> > Can you please clarify what you mean by "impairing"? If you're using the Mozilla Trust Store to make decisions outside of the Mozilla purview. That is, it has three trust bits, only one of which has an audit requirement - namely, the Website bit requires
BR AND Mozilla Policy compliance. The Mozilla Policy compliance ALREADY requires (effectively) that all certificates (transitively) be BR compliant. So if there is an incompatibility in schemes, these users are already "impaired"<br>
>> ><br>
>> > <br>
>> ><br>
>> > And Mozilla's made it clear the risks these groups run if they're using the NSS trust store outside of NSS - <a href="https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F" target="_blank">https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F</a>
- so I don't think that's a consideration the Forum should engage in, as Mozilla's already explicitly disclaimed it.<br>
><br>
><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">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>
</div>
</body>
</html>