At 10:08 PM +0100 1/23/08, Anders Rundgren wrote:
Certificates with wildcards are fairly widely used because they can save you both hassles and money.Issuer: https://www.godaddy.com/gdshop/ssl/ssl.asp?ci=8979 A major issuer of SSL certs.That is, it does not matter what 3280bis says, this is de-facto standard and I doubt that Microsoft intends to remove support for this in MSIE. If an issuer creates a certificate for *.com it is a bad issuer while *.mycompany.com is ok. Bad issuers don't have their roots deployed in browsers so I don't see what the problem is. If you have bad issuers nothing really helps. Anders
Putting a DNS name into the CN attribute is bad behavior. It was one thing for CAs to do this when there was no SAN that could represent a DNS name, but that has not been the case for years. Inserting an invalid DNS name construct, e.g., one with an asterisk, into that attribute is more egregious bad behavior.
The situation you describe seems to be:- a CA generates a cert that contains a CN value that looks like a DNS name, but is syntactically NOT a DNS name
- a provider of browser software decides to ascribe semantics to this CN value.
- the browser uses this interpretation to make a security relevant decision on behalf of the user, e.g., when validating a cert for a web site
- the syntax and semantics adopted by the CA and enforced the browser vendor are not consistent with the standards that describe certs nor their interpretation by browsers as defined by the cognizant IETF WGs (i.e., PKIX & TLS).
Most folks would consider this a bad outcome, as it undermines interoperability as promoted through the use of open standards.
The fact that you view this sort of collusion between a CA and a browser vendor as a legitimate way to create a (de facto) standard suggests that maybe you ought not waste your time in non-de facto standards activities, e.g., PKIX.
Steve