<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 15 (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;}
/* 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 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.<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">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?
<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 agree with Ryan that changes to the certificate profile needs to be gradual.
<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">Kelvin<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"><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"><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"> public-bounces@cabforum.org [mailto:public-bounces@cabforum.org]
<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<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>
<p><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<o:p></o:p></p>
<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.<o:p></o:p></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.<o:p></o:p></p>
<p>The changing of the certificates themselves can then be accomplished over a slower time period, and carefully.<o:p></o:p></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.<o:p></o:p></p>
</div>
</body>
</html>