<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 21, 2016 at 7:07 AM, Peter Bowen <span dir="ltr"><<a href="mailto:pzb@amzn.com" target="_blank">pzb@amzn.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think you are overstating the security and interoperability risks.  Based on data form CT logs, a very large number of different CA operators have issued current (unexpired) certificates  with IP addresses in the dNSName type (not just Symantec) and there have been no obvious interoperability problems.  As you so kindly pointed out in a message a few days ago, there is going to be no confusion between an IPv4 address presented as a dotted octet string and a public domain name.<br></blockquote><div><br></div><div>I'm afraid you've misunderstood my concern. An implementation on the client that enforces RFC5280 here will rightfully reject such certificates, as the labels to not conform to the LDH rule - that is, a domain name constructed entirely of numbers is an invalid hostname, the dNSName field should only contain valid hostnames, and such are rejected.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Due to this, the “technically constrained Sub-CA” (TCSA) risk you suggest does not exist.  According to the TCSA rules, the list of allowed names must be included in the permittedSubtree field (that is it is whitelisting names).  IP addresses in DNSName will not match the DNSName constraints, so it would be no different than a TCSA constrained to “<a href="http://example.com" rel="noreferrer" target="_blank">example.com</a>” issuing a certificate for “<a href="http://www.gmail.com" rel="noreferrer" target="_blank">www.gmail.com</a>”.  This will effectively mean that TCSAs will not be able to take advantage of this compatibility option (unless they happen to have authority over an old-style Class A, B, or C IP range).<br></blockquote><div><br></div><div>You're right, in that I improperly specified the concern. The underlying security risk, however, still applies - a certificate with an iPAddress nameConstraint, but without a dNSName constraint (thus admittedly not meeting the definition of a technically constrained sub-CA, but still being constrained), will still be able to produce certificates which evade that technical control and violate RFC5280.</div><div><br></div><div>That is, a sub-CA with a scope of</div><div>permittedSubtrees:</div><div>  IP:<a href="http://192.168.0.1/0.0.0.0">192.168.0.1/0.0.0.0</a></div><div><br></div><div>Will be able to issue a certificate with</div><div>commonName:8.8.8.8</div><div>subjectAltName:</div><div>  dNSName:8.8.8.8</div><div><br></div><div>According to the ballot as proposed. Under the existing BRs, the certificate would have to be constructed as such:</div><div>commonName:8.8.8.8</div><div>subjectAltName:</div><div>  iPAddress:8.8.8.8</div><div><br></div><div>Under the current form, the iPAddress subjectAltName will be properly constrained to the nameConstraints of the issuing CA, as per RFC 5280. Under the proposed form, the absence of the iPAddress subjectAltName means that the permittedSubtrees of the sub-CA is ignored; a client that then does a textual match against the commonName (e.g. as the majority do) will now improperly accept it as valid according to RFC 5280, despite violating the expressed policies. Applications would need to be updated to apply additional checks, outside of RFC5280 (and thus difficult to implement in common validation libraries that conform to RFC5280), to ensure that before they accept such a commonName, they constrain it to the iPAddress permittedSubtrees (if it's "IP shaped").</div><div><br></div><div>The key difference here is that such a 'hostile' certificate would be fully conforming to the BRs, as presently worded (although I'd appreciate if I missed something). While one might argue that such a policy is good for defense in depth (e.g. avoiding BR-violating certs), it's difficult to argue intentionally introducing this vulnerability.</div><div><br></div><div>One might change the proposal, to require that if an IP is present in the dNSName SAN, then it MUST ALSO be present in an iPAddress SAN. That is, a BR conforming cert would have to encode as:</div><div><br></div><div>commonName:8.8.8.8</div><div>subjectAltName:</div><div>  dNSName:8.8.8.8</div><div>  iPAddress:8.8.8.8</div><div><br></div><div>There, a conforming RFC5280 compliant implementation will properly reject the certificate as violating the name constraints. While an 'evil subCA' could issue a certificate</div><div><br></div><div>commonName:8.8.8.8</div><div>[subjectAltName omitted]</div><div><br></div><div>Which would trigger the evasion behaviour described above, such a certificate is "clearly" non-conforming to the BRs.</div><div><br></div><div>And of course, there's no guarantee that the solution I proposed above - one to protect users - would actually be deployable in practice and not trigger bugs in other clients. Which is why the idea of "let's just violate the BRs" is so deeply discouragingly problematic.</div></div></div></div>