<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Salz, Rich via RT <span dir="ltr"><<a href="mailto:rt@openssl.org" target="_blank">rt@openssl.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Note that other implementations treated this as a bug and fixed it a long time<br>
> ago.<br>
<br>
</span>What other implementations, and what did they do?  Always treating a CN as a DNS name?  We can't.<br></blockquote><div><br></div><div>As one example, mozilla::pkix treats the CN as a dNSName/iPAddress iif there is no subjectAltName extension and iif the CN is a valid dNSNa/iPAddress syntactically.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Applications can do that now by setting the right flag, as Viktor pointed out.  I think it's too late to make the default change for 1.1<br></blockquote><div><br></div><div>The important thing is: What happens when applications use the default settings? If the default settings are "don't consider the subject CN for name constraint processing, but do consider it for name validation" then that's obviously wrong and dangerous.</div><div><br></div><div>Besides that, there needs to be a way to make name constraint processing consistent with name validation. That means that if name validation is configured (by default or with a switch) to look at subject CNs then the name constraints need to be configurable to do the same. Name validation and name constraint validation go hand-in-hand.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> How about this for a heuristic:  If nameConstraints are in effect, then the<br>
> validator MUST NOT accept the CN as a DNS name.  This seems like the least<br>
> the validator could do, in light of the aforementioned deprecation.<br>
<br>
</span>Probably.<br></blockquote><div><br></div><div>If the validator has that much information then it should be simple for it to keep the state in sync. But, often (usually?) certificate chain validation and certificate name validation are done in separate steps by applications, and it's difficult or impossible to keep things in sync in that case.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>  -- The problem is not solved until bad guys are<br>
>   /required/ to use SAN;<br>
<br>
</span>Applications can make that happen now.</blockquote><div><br></div><div>Again, what matters is less what applications *can* do and more what applications *actually* do. I suspect that most applications are having the wrong, dangerous, thing happen. In fact, that is almost definitely the case, considering that many applications are doing their own name validation (and thus almost definitely looking at the subject CN as that is historically how it is done), as OpenSSL didn't provide a name validation API until recently.</div><div><br></div><div>So, I agree with the others that OpenSSL is broken in this respect.</div><div><br></div><div>Cheers,</div><div>Brian</div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><a href="https://briansmith.org/" target="_blank">https://briansmith.org/</a></div><div><br></div></div></div></div></div></div></div>
</div></div>