<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.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
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:windowtext;}
.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'>We (and other CAs) have customers who are putting together an explanation of the need. It’s only been a few days. Plus, I’m not sure customer input sways many people on the Forum. Would it really make a difference to you if a couple of customers chimed in? I hate to waste their time if it really isn’t going to make a difference what they say.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>“</span>Instead, we see CAs eager to violate RFC5280, easy to cause compatibility issues with clients, and w/o apparent care for the long-term damage to the ecosystem they would be doing”<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>What is the long term damage again? Putting IP addresses in the dNSName has been around for a long time. I don’t see how this is causing long-term damage to the ecosystem. <span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Multiple CNs don’t work well. I’m hoping we can share specifics next week.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Jeremy<o:p></o:p></span></p><p class=MsoNormal><a name="_MailEndCompose"><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></a></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> Friday, April 22, 2016 3:45 PM<br><b>To:</b> Peter Bowen <pzb@amzn.com><br><b>Cc:</b> Rick Andrews <Rick_Andrews@symantec.com>; public@cabforum.org<br><b>Subject:</b> Re: [cabfpub] Proposed new ballot on IP Addresses in SANs<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Fri, Apr 22, 2016 at 12:45 PM, 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>So it would seem that this solution might not be the best option.<o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>"Not the best" isn't the goal. It's "Don't violate RFC5280" that should be the goal.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Multiple SANs is a complete red-herring as to the issue. There's no requirement that such certificates have them.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Common name deprecation is equally a red-herring. If it offers a viable path for these clients, without the attendant security issues and *fundamental violation of RFC5280*, it's worth exploring.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>That there's been no further explanation other than "Meh" is, unquestionably, not a position we can endorse, but even moreso, a policy of "Oh well, we'll violate them anyways" is just grossly irresponsible.<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><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>The best solution would be for clients to be updated to follow RFC 2818 and check iPAddress entries in the SAN.<o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Indeed, and Microsoft can solve this very easily, without the same risks and compatibility issues of nameConstraints.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>We considered the RFC5280 non-criticality of nameConstraints because it offered significant positive security value for a majority of clients, without compatibility risks. The iPAddresses provide no positive security value - other than allowing CAs to sell to users with buggy software that their vendor doesn't want to fix - and come with significant compatibility and security risks.<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><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><br>To me, it seems that allowing string-ified IP address in dNSName entries in the SAN when the same IP address is included as an iPAddress entry in the SAN is a reasonable tradeoff. It is no worse than including the same in the common name. As you have pointed out, a string-ified IP address can never match a hostname, so there is no chance of confusion <o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I've already explained to you why this is incorrect. It's unfortunate that you continue to suggest this line of thinking. A string-ified IP address is not a valid hostname.<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><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>If you have a client that properly conforms to RFC 2818, then this is a no-op for you — you will look at the IPaddress entry and never try to match on DNSname. You had expressed concern that Mozilla would need to update its code, but Gerv had indicated back in August that this was not necessary (<a href="https://cabforum.org/pipermail/public/2015-August/005850.html" target="_blank">https://cabforum.org/pipermail/public/2015-August/005850.html</a>).<o:p></o:p></p></blockquote><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal>That's not what is in the ballot. What is in the ballot can and will cause compatibility issues. It also suggests that Chrome would need to adopt Firefox's peculiar behaviour (only validating presented identifiers as they're encountered, rather than at parse time). That's not something we are comfortable with implementing, and especially not foisting upon the ecosystem to know about the "special" rules the CA/B Forum embraces. There's already enough magic in the WebPKI - we shouldn't knowingly introduce more.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><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 appreciate that conformance is a great goal, but not causing customer pain is also a laudable goal. In this case it seems the risk is low and the customer value is high.<o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>There has yet to be a demonstration of the customer value compared to the solution posed 8 months ago. There's clearly a demonstration of CA value - they do less work - and of browser value - Microsoft does less work - but there has yet to be an articulation of why the solution is non-viable. The closest comment is Jeremy saying they've investigated, it's not practical - but provided zero evidence or technical detail that would allow a reasoned weighing of the risk versus reward. Instead, we see CAs eager to violate RFC5280, easy to cause compatibility issues with clients, and w/o apparent care for the long-term damage to the ecosystem they would be doing.<o:p></o:p></p></div></div></div></div></div></body></html>