<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: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:UICTFontTextStyleBody;}
/* 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;}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;
        font-weight:normal;
        font-style:normal;}
.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'>Ryan,<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'>Today, we and other CAs issue certificates to customers for use both (a) publicly and with browsers, and (b) privately on internal networks and/or with non-browser applications. Currently, these certificates all have a TLS serverAuth EKU, all are in-scope with the BRs, and all comply with the BRs. They all are issued from roots that appear in browser and OS trust stores.<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'>However, we believe that if a CA issues a certificate (1) with a TLS serverAuth EKU, that (2) chains to a root that is not in browser or OS trust stores, then those certificates are not in scope nor need to comply with the BRs. We’ve discussed this before in the CA/B Forum and there seems to be consensus among the Forum members, including auditors. <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'>The issue that we’re raising here is that today the same roots, those trusted by browsers, are used for both public and private applications. This creates unnecessary complexity and delays in moving initiatives in the CA/B Forum forward as we have to solve for both the public and private use cases. What we’re recommending is finally to make these use cases clearly distinct for customers (clearly using different roots for the public vs. private cases and the clarifying the implications of choosing one vs. the other) and to provide a transition period to do so.<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'>This will serve not only this topic of transparency but also allow us the ability to move faster than before to move forward other important changes when it comes to publicly trusted certificates.    <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'>-Rick<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 style='margin-left:.5in'><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> Wednesday, December 09, 2015 7:05 PM<br><b>To:</b> Rick Andrews<br><b>Cc:</b> public@cabforum.org<br><b>Subject:</b> Re: [cabfpub] Misissuance of certificates<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><div><p class=MsoNormal style='margin-left:.5in'>On Wed, Dec 9, 2015 at 6:39 PM, Rick Andrews <<a href="mailto:Rick_Andrews@symantec.com" target="_blank">Rick_Andrews@symantec.com</a>> wrote:<o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:16.0pt;font-family:UICTFontTextStyleBody'>Ryan,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:16.0pt;font-family:UICTFontTextStyleBody'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:16.0pt;font-family:UICTFontTextStyleBody'>Yes, that’s what I mean by private (not subject to the BRs).</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:16.0pt;font-family:UICTFontTextStyleBody'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:16.0pt;font-family:UICTFontTextStyleBody'>The concerns I raised still apply... today it is common practice for customers to use certificates from roots trusted by browsers for private and/or non-browser use cases. The ballot needs an implementation date in the future to allow us and other CAs time to implement options for customers that distinguish these private/non-browser certificates, to make sure customers are aware of how these new rules relate to the future disclosure of publicly-accessible certificates, and to allow customers to replace their existing certificates where needed. This is why we proposed the interim disclosure approach, where prior to that implementation date, disclosure would still happen, but with the subject details redacted.</span><o:p></o:p></p></div></div></div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>Rick,<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>A few points of clarification, to make sure I am fully understanding your message.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>When you say 'private and/or non-browser use cases', is it correct to understand this as:<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>1) Certificates that have a TLS serverAuth EKU<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>2) Certificates that are in-scope with the Baseline Requirements<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>3) Certificates that comply with the stipulations set forth in the Baseline Requirements<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>If you have 1, then it should be well understood that you also have 2, and thus necessarily also have 3, but I wanted to confirm that #1 is true.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>However, your reply "private, not subject to the BRs" and "from roots trusted by browsers" seems very much incompatible, if 1 is true, and if this is the case, then we need to resolve this understanding as soon as possible, as such an understanding seems incompatible with a number of root program agreements.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>If you have #1, however, I have trouble understanding how it _isn't_ a matter of public interest and trust when such a certificate is misissued, and thus would like to try to further understand the reasoning.<o:p></o:p></p></div></div></div></body></html>