Re: Handling of wildcard certificates (ACTION-519)

Right now we're using WinHTTP (Microsoft's library). It displays an error.
We will be switching to our own network stack soon, but our behavior will
probably still depend on the underlying API for the the platform (e.g.
schannel on Windows, Secure Transport on OS X, openssl on Linux). We could
probably override this, but allowing this doesn't feel wrong (the CA issued
it after all), and not allowing it also doesn't feel wrong (it's such a
corner case that nobody seems to use) that frankly I don't really think it
matters what we do.
-Ian
On Mon, Oct 6, 2008 at 5:08 AM, Thomas Roessler <tlr@w3.org> wrote:

> Ian, Johnathan,
>
> any follow up to this?  From Yngve's and George's answers, this
> piece certainly isn't as uniformly implemented as one obvious
> interpretation of the specification text would suggest.
>
> Thanks,
> --
> Thomas Roessler, W3C  <tlr@w3.org>
>
>
>
>
>
> On 2008-09-24 18:26:29 +0200, Thomas Roessler wrote:
> > From: Thomas Roessler <tlr@w3.org>
> > To: Ian Fette <ifette@google.com>
> > Cc: Johnathan Nightingale <johnath@mozilla.com>,
> >       George Staikos <staikos@kde.org>, public-wsc-wg@w3.org
> > Date: Wed, 24 Sep 2008 18:26:29 +0200
> > Subject: Re: Handling of wildcard certificates (ACTION-519)
> > List-Id: <public-wsc-wg.w3.org>
> > X-Spam-Level:
> > Authentication-Results: mx.google.com; spf=pass (google.com: domain of
> >       public-wsc-wg-request@listhub.w3.org designates 128.30.52.56 as
> permitted sender)
> >       smtp.mail=public-wsc-wg-request@listhub.w3.org
> > Archived-At: <
> http://www.w3.org/mid/BB8B0B1E-3009-4B33-8B07-09895D5D2551@w3.org>
> > X-Bogosity: Ham, tests=bogofilter, spamicity=0.172818, version=1.1.6
> >
> >
> >
> > On 24 Sep 2008, at 18:22, Ian Fette wrote:
> >
> >> How in the world is this under-specified? It's spelled out as clear as
> >> can be...
> >>
> >>
> >>    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.
> >
> > The question is where and how often the wildcard character can occur.
> >
> > I.e., is f*.*.com acceptable?  foo.*.com?
> >
> >> As for Google Chrome, we follow RFC2818 here, and so if you have a cert
> >> for *.a.com we will show a warning for bar.foo.a.com. So far as I can
> >> tell, IE and Safari also do the same.
> >
> > That would be the obvious case.  The question was about cases like the
> > one above, in which at least Opera seems to have different behavior.
> >
> >>
> >> On Wed, Sep 24, 2008 at 9:15 AM, Thomas Roessler <tlr@w3.org> wrote:
> >> Hello,
> >>
> >> during today's call, we realized that RFC 2818 seems underspecified in
> >> terms of what's permissible in wildcard certificates; Yngve told us that
> >> Opera only accepts the wildcard in the first label of a DNS name that
> >> appears in a certificate.
> >>
> >> I.e., *.bar.com can match foo.bar.com, but foo.*.com wouldn't match
> >> foo.bar.com, in Opera.
> >>
> >> How do Mozilla and Chrome and Konqueror behave?
> >>
> >> Thanks,
> >> --
> >> Thomas Roessler, W3C   <tlr@w3.org>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>
>