[Patch] Non-permissive subjectAltName wildcard

[Jean-Philippe Garcia Ballester]

On Sunday 04 May 2008, Nikos Mavrogiannopoulos wrote:
> Andreas Metzler wrote:
> > Hello,

  Hello,
  First, thanks for replying that quickly :)

> > this http://bugs.debian.org/479174 reported by Jean-Philippe Garcia
> > Ballester:
> >
> > On 2008-05-03 Jean-Philippe Garcia Ballester <giga at le-pec.org> wrote:
> >> It seems too me that the subjectAltName wildcard matching has strong
> >> constraints.
> >>
> >> First, it allows only one wildcard. Since a wildcard can only match
> >> a single domain component, multiple wildcards are useful (e.g.,
> >> *.*.example.org). I did not see in the rfc 2818 such restriction.
>
> Thank you for the patch. I need some clarifications before including it
> though. Having such as permissive wildcard is quite dangerous. Why would
> one specify *.*.example.org instead of the much simpler *.example.org?

  Because *.example.org does not match www.intranet.example.org, according to 
the RFC (and the current implementation).
  Of course, listing all the subdomains can be done, but the wildcard was 
introduced specifically to avoid re-issuing a new certificate each time a new 
sub-domain is used.

> >> Second, it only allows the wildcard to be at the beginning of the
> >> hostname.  Since the rfc 2818 gives “f*.com” as an example, I
> >> believe this is a false assert.
>
> f*.com is not a good example :) I don't think that such a wildcard
> certificate has a real world usage, and if any CA signs it would be at
> error. Of course this applies to *.com as well...

  Obviously, but as you say, I believe it is the CA's job not to sign such a 
certificate, not the library's job.

> Probably your point is for wildcards such as test*.gnutls.org?

  The truth is that the real problem was the first thing above. While fixing 
this issue, I read the RFC and found the two others “problems”.
  I do not a have a “real world” example, since I don't have any use for this. 
I just thought that if the RFC allows it, then the software should.
  Maybe it could be of use for self-signed certificates used in private 
intranets.

> >> Third, it only allows the wildcard to be followed by a ‘.’. This is
> >> not clearly stated in the rfc, but I believe it is reasonnable to
> >> assume that if “f*.com” is allowed, then “f*o.com” should be allowed
> >> as well.
>
> What is your use case that does not work by the current simple wildcard?

  Again, none. But I believe there are people in this world bizarre enough to 
have a use case for this. For example, people using suffix instead of 
sub-domain, e.g. ‘www-intranet.example.org’ (though I do not see any reason 
for doing so, maybe some people do).

  If you do not want to fix these issues, which I would totally understand 
because of my lack of arguments, please at least document it somewhere.
  It took me a while to figure out where the problem was, because I usually 
make the assumption that softwares correctly implement RFC (which might be a 
big mistake ;) ).

  Regards,

-- 
Jean-Philippe Garcia Ballester
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20080504/cb213efb/attachment.pgp>