Re: looking for terminology recommendations concerning non-rooted FQDNs

[Owen DeLong <owen () delong com>]

On Feb 25, 2013, at 9:18 AM, Jay Ashworth <jra () baylink com> wrote:

> ----- Original Message -----
> > From: "Owen DeLong" <owen () delong com>
>
> > However, that's for the resolver library. In terms of matching the CN
> > in a certificate, this should always be FQDN and the trailing dot
> > should not be present. If OpenSSL (the command line tool) is passing
> > foo.blah.com. to the SSL functions and not just getaddrinfo(), then,
> > it is a bug.
>
> If I understood Brian correctly, his problem is that people/programs
> are trying to retrieve things from, eg:
>
> https://my.host.name./this/is/a/path
>
> and the SSL library fails the certificate match if the cert doesn't contain
> the absolute domain name as an altName -- because *the browser* (or whatever)
> does not normalize before calling the library.
>
> As I suggest in another thread, I think the SSL library probably ought to
> be normalizing off that trailing dot itself, before trying to match the
> string supplied to the names in the retrieved cert.
>
> It sounds as if you might agree with me, at least in principle.

I don't see any reason that the SSL library shouldn't normalize the
name and remove the trailing dot.

However, even if the SSL library does so, I see no valid reason that
would relieve the browser of the obligation to do so as well.

Be conservative in what you send (or pass to a library) and liberal
in what you accept.

Under that principle, the SSL library should accept either one and
normalize it. However, the browser should also normalize what it
passes to the SSL library.

Owen