Should host/domain names travel over the internet with a trailing dot?

Mon Feb 25 16:30:07 UTC 2013

On Mon, Feb 25, 2013 at 11:26:47AM -0500, Jay Ashworth wrote:
> > The upshot (assuming I'm not totally off base here), is that other
> > than getaddrinfo(), nothing is acting on the semantics of the
> > supplied hostname (or IP address). They are 'just strings', and
> > are (essentially) compared as such.
> 
> Right.  And I'm asserting that that's wrong: the client side libraries
> Really Ought To normalize that name before trying to compare it against
> the retrieved certificate to see if it matches, which would relieve you
> of having to have the altName with the trailing dot in such a cert.

I know for internal testing, I've had to introduce unqualified
hostnames in the CSR as well (e.g. 'testhost', instead of
'testhost.example.com'), to handle the case of the client not using
domain names at all (when framing queries).  This illustrates that
there's not even an effort to synthesize a FQDN.

Who should implement the normalization logic?  Not the SSL library,
certainly.  That sounds like the bailiwick of the resolver library...

> The controlling standard *appears* to be RFC 2246, TLS v1.0.  I'm doing
> some work this morning, but that's up in a tab for coffee breaks; I'll 
> try to figure out what I think Dierks and Allen thought about this topic,
> if anything, during the day.

I look forward to the fruits of your research. :)

> Cheers,
> -- jra
> -- 
> Jay R. Ashworth                  Baylink                       jra at baylink.com
> Designer                     The Things I Think                       RFC 2100
> Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
> St Petersburg FL USA               #natog                      +1 727 647 1274

-- 
Brian Reichert				<reichert at numachi.com>
BSD admin/developer at large	