<p dir="ltr"><br>
On Nov 20, 2014 6:03 AM, "Gervase Markham" <<a href="mailto:gerv@mozilla.org">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</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">The changing of the certificates themselves can then be accomplished over a slower time period, and carefully.</p>
<p dir="ltr">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.</p>