<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>Ryan - <span style="font-size: 12pt;">Agree</span><span style="font-size: 12pt;"> that your solution hasn't been discussed. You said:</span></p>
<pre>The argument seemingly provided on the bug is for compatibility with
Microsoft products prior to Windows 10 - which lack support for iPAddress
subjectAltNames, but which accept IP addresses in both the common name and
in the dNSName subjectAltNames because they treat the name to match as a
(mostly) opaque string. However, the compatibility issue does not
necessitate violating the Baseline Requirements or RFC 5280, as a CA could
fully adhere to the BRs by expressing an iPAddress SAN with the IP in the
common name. The absence of a dNSName SAN (and the lack of support for
iPAddress SAN) will result in the CN being treated as a "domain", and then
matching with the opaque string.
It does mean that you _cannot_ mix and match hostnames and IP addresses in
publicly trusted certificates, due to the compatibility issues, but I
thought it was well understood by CAs as a necessary tradeoff in order to
conform to the relevant technical standards and audit criteria.</pre>
<p>Does this mean a 'certificate containing an IP address in the CN and only that same IP address encoded as IPAddress in the first SAN entry?' In addition, does it imply:</p>
<p>- no other SAN entries will be recognized, due to a different compatibility issue (Firefox?)</p>
<p>- The cert can only support a single IP (only a single CN is allowed)</p>
<p>- Can't deprecate CN as long as this workaround is required</p>
<div id="Signature">
<div name="divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div><br>
</div>
</div>
</div>
<div style="color: rgb(0, 0, 0);">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> public-bounces@cabforum.org <public-bounces@cabforum.org> on behalf of Ryan Sleevi <sleevi@google.com><br>
<b>Sent:</b> Saturday, April 16, 2016 9:37 AM<br>
<b>To:</b> Rick Andrews<br>
<b>Cc:</b> public@cabforum.org<br>
<b>Subject:</b> Re: [cabfpub] Proposed new ballot on IP Addresses in SANs</font>
<div> </div>
</div>
<div>
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, Apr 16, 2016 at 9:31 AM, 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>I disagree with the tone that CAs are entirely to blame here. </div>
</div>
</blockquote>
<div><br>
</div>
<div>Why? I provided you evidence on how you could have issued such certificates without violating the BRs.</div>
<div><br>
</div>
<div>The fact that you:</div>
<div>1) Seemingly did not attempt to discover this yourself</div>
<div>2) If you did attempt, were unable to, and did not seek for outside input</div>
<div>3) When you did receive outside input, ignored it</div>
<div>4) Have continued to argue that it's necessary, without providing any response in over 8 months show that it isn't</div>
<div><br>
</div>
<div>Shows that the CAs doing this ARE entirely to blame.</div>
<div> <br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<div dir="auto">
<div><span style="">The BRs are baseline requirements, and browser vendors often say that they have the right to impose additional requirements above and beyond the BRs. When that happens, though, it sometimes puts CAs in a bind. </span></div>
</div>
</blockquote>
<div><br>
</div>
<div>And by a bind, it means you'd like to do something, but can't, besides browsers say you shouldn't. That isn't a bind - that's how security works. You can't be simultaneously trusted to be the bastion of online security while also engaging in insecure practices.
That isn't how trust works.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<div dir="auto">
<div>
<div><span style="">This is a case in which the BRs say we can't do something, but one browser vendor says we can.</span></div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I'd love to hear that from Jody, given the evidence.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<div dir="auto">
<div>
<div><span style="">Ideally, Microsoft would have recognized this back before the BRs were adopted, and addressed it in their platform or lobbied to rewrite the requirement.
</span></div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>"And addressed it in their platform" - but they did, as you yourself have said. Windows 10 addressed this.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<div dir="auto">
<div>
<div><span style="">But that didn't happen. We're trying to rectify the situation now. </span></div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>You're not trying to rectify it. If you were, you would have explored 8 months ago what I proposed, and reported back to the Forum why it wasn't viable.</div>
<div><br>
</div>
<div>And let's be clear here: there's a big difference between "not viable" (e.g. it doesn't work) and "not desirable" (e.g. our customers or we have to do more work). Given the role that CAs play in the online trust ecosystem, the goal is not to enable every
business desire a CA has, nor to encourage or bless every practice that violates standards. It's to make a balanced tradeoff between risk, reward, and standards. I have seen no evidence of good-faith effort on your part in the past 8 months to strike that
balance, because if there had been, the line of reasoning for this change wouldn't be what you're presently arguing.</div>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</body>
</html>