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.