<div dir="ltr">While I wish it was true that Section 17 covered it, the loophole is in Section 1 - "This version of the Requirements only addresses Certificates intended to be used for authenticating servers
accessible through the Internet"<div><br></div><div>That is, if you don't meet Section 1's Scope, surely Section 17's audit requirements don't apply - or so the argument goes. Aligning Section 17 with Section 1 is needed, but as multiple CAs have raised during the past meetings, that means that all of their (code signing, e-mail, etc) certs would fall under the criteria of Section 17. So we need a way to make Scope 1 inclusive (measured by capability, not intent, like Section 17), but also sufficiently exclusive (such as using id-kp-serverAuth) that the existing (code signing, email, etc) intermediates don't run afoul OR are entirely covered by the audits.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 20, 2014 at 7:06 PM, Kelvin Yiu <span dir="ltr"><<a href="mailto:kelviny@exchange.microsoft.com" target="_blank">kelviny@exchange.microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I agree the audit requirements needs to be clearer since section 17 of the current BR already requires all unconstrained CAs to be audited. However, the list
of audit schemes is horribly out of date. For example, referencing ETSI TS 102 042 without specifying the certificate policy is insufficient. The list may contradict with browser requirements (for example, Microsoft no longer accept ISO 21188 audits). It also
feels like circular reference.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Instead of each browser root program maintaining their own separate audit requirements, would it be better for the CABF as a body to maintain a list of suitable
audit criteria (along with the version of the audit criteria and possibly auditor qualification information) in a separate guidelines document that browsers can reference?
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I agree with Ryan that changes to the certificate profile needs to be gradual.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Kelvin<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> <a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a> [mailto:<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a>]
<b>On Behalf Of </b>Ryan Sleevi<br>
<b>Sent:</b> Thursday, November 20, 2014 8:41 AM<br>
<b>To:</b> Gervase Markham<br>
<b>Cc:</b> CABFPub<span class=""><br>
<b>Subject:</b> Re: [cabfpub] (Eventually) requiring id-kpServerAuth for all certs in the chain?<u></u><u></u></span></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p><br></p><div><div class="h5">
On Nov 20, 2014 6:03 AM, "Gervase Markham" <<a href="mailto:gerv@mozilla.org" target="_blank">gerv@mozilla.org</a>> wrote:<br>
><br>
> On 19/11/14 23:21, Jeremy Rowley wrote:<br>
> > I think Ryan’s suggestion is best. If all intermediates capable of SSL<br>
> > issuance are BR audited, then there isn’t an issue. You still need to<br>
> > disclose their existence in accordance with the Mozilla policy, but<br>
> > there won’t be a need to reissue the certs.<br>
> ><br>
> > Plus, all the groups I contacted responded that their intermediates are<br>
> > already compliant and wouldn’t have issues with a BR audit. I’d support<br>
> > moving forward with Ryan’s proposal.<br>
><br>
> How does Ryan's proposal differ from Brian's?<br>
><br>
> Brian's proposal, as I now understand it, is basically that we make what<br>
> Mozilla requires (in terms of constrain or disclose-and-audit) part of<br>
> the BRs rather than just Mozilla policy. And we define that the BRs<br>
> cover all publicly-trusted roots, all disclosed-and-audited<br>
> intermediates, and certificates issued from them.<br>
><br>
> Gerv<u></u><u></u></div></div><p></p><div><div class="h5">
<p>Correct. That's what I proposed and explained during the Mountain View F2F. That addresses the short-term auditing gap without requiring mass reissuance by CAs and dealing with the attendant PKI complexities involved when customers fail to update their sites.<u></u><u></u></p>
<p>I realize mozilla::pkix leaves Firefox in a better place than it was historically. Buy there are still a number of clients (notable among them both Android and iOS, but also OS X) that are more finicky.<u></u><u></u></p>
<p>The changing of the certificates themselves can then be accomplished over a slower time period, and carefully.<u></u><u></u></p>
<p>Coupling the audit coverage clarification to a massive certificate change does not seem advisable, which is why I proposed this even prior to Mozilla adopting it.<u></u><u></u></p>
</div></div></div>
</div>
</blockquote></div><br></div>