<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;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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'>Agreed – and a very poor statement of inclusion since the proof is completely subjective on whether the user intended the cert for server authentication. We’ve already seen cases where the cert is clearly able to be used for server authentication even if the intent wasn’t originally there. Sure the proposal I made was deficient, but it at least gave a date when all certs would be compliant (even if it is 5 years down the roead). Right now there is no future date when all certs would be compliant. <o:p></o:p></span></p><p class=MsoNormal><a name="_MailEndCompose"><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></a></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><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>Peter Bowen<br><b>Sent:</b> Monday, January 25, 2016 7:45 PM<br><b>To:</b> Ryan Sleevi<br><b>Cc:</b> CABFPub<br><b>Subject:</b> Re: [cabfpub] Defining BR scope<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal>On Jan 25, 2016, at 1:39 PM, Ryan Sleevi <<a href="mailto:sleevi@google.com">sleevi@google.com</a>> wrote:<o:p></o:p></p></div><div><div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Fri, Jan 22, 2016 at 8:07 AM, Peter Bowen <<a href="mailto:pzb@amzn.com" target="_blank">pzb@amzn.com</a>> wrote:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p class=MsoNormal>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.<o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div></div></div></div></div></blockquote><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The BRs state:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>"These Requirements only address Certificates intended to be used for authenticating servers accessible through the Internet. Similar requirements for code signing, S/MIME, time<span style='font-family:"Cambria Math",serif'>‐</span>stamping, VoIP, IM, Web services, etc. may be covered in future versions.”<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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”.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Thanks,<o:p></o:p></p></div><div><p class=MsoNormal>Peter<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>