Mads Kiilerich <m...@kiilerich.com> added the comment: Nicolas Bareil wrote, On 05/07/2011 09:48 AM: > Do you think this test should fail?
Until now I have considered this behaviour OK but undocumented and officially unsupported in Python. One (the best?) reason for considering it OK is that if someone (intentionally or not) trusts a certificate that happens to have the textual representation of an IP address in commonName then there is no doubt what the intention with that is. This case is thus within what i considered secure behaviour. But the more I look at it the more convinced I get that this test should fail. RFC 2818 mentions subjectAltName iPAddress as a "must" for IP addresses - even though it only uses a lower-case and thus perhaps-not-necessarily-authoritative "must". But the best argument against IP in commonName is that it isn't mentioned anywhere, and when it isn't explicitly permitted we should consider it forbidden. A consequence of that is that my previous concern is invalid. There is no reason the presence of a subjectAltName iPAddress should prevent fallback from dNSName to commonName. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12000> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
