<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 9, 2015 at 6:39 PM, Rick Andrews <span dir="ltr"><<a href="mailto:Rick_Andrews@symantec.com" target="_blank">Rick_Andrews@symantec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><p class="MsoNormal"><font face="UICTFontTextStyleBody"><span style="font-size:21px;background-color:rgba(255,255,255,0)">Ryan,<u></u><u></u></span></font></p><p class="MsoNormal"><font face="UICTFontTextStyleBody"><span style="font-size:21px;background-color:rgba(255,255,255,0)"> </span></font></p><p class="MsoNormal"><font face="UICTFontTextStyleBody"><span style="font-size:21px;background-color:rgba(255,255,255,0)">Yes, that’s what I mean by private (not subject to the BRs).<u></u><u></u></span></font></p><p class="MsoNormal"><font face="UICTFontTextStyleBody"><span style="font-size:21px;background-color:rgba(255,255,255,0)"> </span></font></p><p class="MsoNormal"><font face="UICTFontTextStyleBody"><span style="font-size:21px;background-color:rgba(255,255,255,0)">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></font></p></div></div></blockquote></div><br></div><div class="gmail_extra">Rick,</div><div class="gmail_extra"><br></div><div class="gmail_extra">A few points of clarification, to make sure I am fully understanding your message.</div><div class="gmail_extra"><br></div><div class="gmail_extra">When you say 'private and/or non-browser use cases', is it correct to understand this as:</div><div class="gmail_extra">1) Certificates that have a TLS serverAuth EKU</div><div class="gmail_extra">2) Certificates that are in-scope with the Baseline Requirements</div><div class="gmail_extra">3) Certificates that comply with the stipulations set forth in the Baseline Requirements</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div></div>