Subject: Re: Wildcard certificates

From: David Hopwood <[email-masked]>
Date: Wed, 28 Aug 2002 22:01:25 +0000

-----BEGIN PGP SIGNED MESSAGE-----

[[email-masked] added]

Eric Norman <[email-masked]> wrote on ietf-pkix:
> On Wed, 28 Aug 2002, Stefan Santesson wrote:
> > I wonder if anyone on this list have experience/opinions on using wildcard
> > names in SSL server certificates.
[...]
>
> We did some experimentation a few years ago with a mail server that needs
> to support lots of different domains.  We found that wildcards work with
> both Netscape and IE browsers.  However, there is a difference in whether
> a wildcard can span a dot or not.  That is, in one browser (I think it's
> Netscape-Mozilla) *.wisc.edu will match a.b.wisc.edu; in the other,
> you need *.*.wisc.edu to match.  We got around this minor inconvenience
> by using two different IP numbers.

RFC 2818 is very clear about this:

   Matching is performed using the matching rules specified by
   [RFC2459].  If more than one identity of a given type is present in
   the certificate (e.g., more than one dNSName name, a match in any one
   of the set is considered acceptable.) Names may contain the wildcard
   character * which is considered to match any single domain name
   component or component fragment. E.g., *.a.com matches foo.a.com but
   not bar.foo.a.com. f*.com matches foo.com but not bar.com.

Arguably this is specified in the wrong place, though, since it should
apply to any TLS profile that uses PKIX certificates and where the server
is likely to have a DNS name. That includes at least RFCs 2487, 2595, 2716
and 2817, so it would probably be better just to specify it once and for
all in 2246bis.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---

From: Eric Rescorla <[email-masked]>
Date: 28 Aug 2002 17:56:08 -0700

>    not bar.foo.a.com. f*.com matches foo.com but not bar.com.
Note that RFC 2818 is Informational.

As Steve Kent points out, dNSNames cannot contain *s. However, since
CN is the standard place to put the DNS name (much to everyone's
unhappiness) they often contain *s. Don't know if anyone actually
uses dNSName for this.

> and 2817, so it would probably be better just to specify it once and for
Oh boy. ISTR that there was a lot of argument about even using
opaque DNS names as extensions. I suspect that defining semantics
for DNS names in TLS would be contentious.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

---

From: "William I. Bormann" <[email-masked]>
Date: Thu, 29 Aug 2002 11:03:42 -0500

>for DNS names in TLS would be contentious.
A couple of things I think are clear from 3280 (pkix certificate and crl 
profile):

1.   Using dc in place of cn is probably the more correct approach to 
naming the subject of a server certificate, viz., for *.foo.bar.com, use 
dc=*,dc=foo,dc=bar,dc=com instead of cn=*.foo.bar.com.
2.  In the SubjectAltName field you can stick multiple DNS components as 
alternative names for the server.  In my mind, this is the more sensible 
approach, as I'm not too comfortable with using the wildcard approach 
when it comes to more than one system sharing the same certificate.

A question:  has any thought been given to allowing DNS names of the format:

.foo.bar.com

in SubjectAltName?  The matching rules would be analogous to that 
specified for NameConstraints URI?  Does this make any sense?

Bill Bormann
Technical Consultant
Purdue University