<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 25, 2016, at 1:39 PM, Ryan Sleevi <<a href="mailto:sleevi@google.com" class="">sleevi@google.com</a>> wrote:</div><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 22, 2016 at 8:07 AM, Peter Bowen <span dir="ltr" class=""><<a href="mailto:pzb@amzn.com" target="_blank" class="">pzb@amzn.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I don’t disagree with this assessment, but the current state of affairs, as I understand it, is that any end-entity certificate that is clearly not for server authentication is already excluded. Many browsers (or should I say ASSes to be BR compliant?) already operate trust stores that recognize a single root to be trusted to issue various kinds of certificates. Mozilla recognizes kp-emailProtection in addition to kp-serverAuth (and still includes kp-codeSigning for many roots), Microsoft recognizes six key purposes other than kp-serverAuth (and includes another four for many roots), and Apple seems to have many recognized key purposes.<br class=""></blockquote><div class=""><br class=""></div><div class="">I'm not sure I understand your remark that "any end-entity certificate that is clearly not for server authentication is already excluded.", and was hoping you could explain you see how that flows. I can speculate the reasoning, but would probably explain it poorly, so I was hoping you could expand on where you see the non-BR compliance carveouts being.</div></div></div></div></div></blockquote><br class=""></div><div>The BRs state:</div><div><br class=""></div><div>"These Requirements only address Certificates intended to be used for authenticating servers accessible
through the Internet. Similar requirements for code signing, S/MIME, time‐stamping, VoIP, IM, Web services,
etc. may be covered in future versions.”</div><div><br class=""></div><div>This language is in v1.3.1 and was in v1.0. Based on the wording, I think it is clear that it is a statement of inclusion rather than a statement of exclusion, meaning that the default state is not covered by BR and Certificates are only covered by BR when they are "intended to be used for authenticating servers accessible through the Internet”.</div><div><br class=""></div><div>Thanks,</div><div>Peter</div><div><br class=""></div><div><br class=""></div></body></html>