looking for terminology recommendations concerning non-rooted FQDNs

Sat Feb 23 13:10:20 UTC 2013

In message <20130222215502.GD99258 at numachi.com>, Brian Reichert writes:
> On Fri, Feb 22, 2013 at 12:41:33PM -0500, Jay Ashworth wrote:
> > My snap reaction is to say that nothing should ever be *trying* to
> > compare a rooted F.Q.D.N. against a certificate; it is, as has been
> > noted, merely command line/entry field shorthand to tell the local
> > resolver where to quit; applications should all be stripping that 
> > trailing dot.
> > 
> > Do you have evidence that the extra AltName with the trailing dot
> > is operationally necessary?
> 
> 'Necessary' is what's hard to ascertain here.
> 
> If, under a UNIX-like operating system, you request a PTR with some
> command-line tool such as 'dig', you'll get a rooted domain name:
>   
>   $ dig -x 8.8.8.8 +short
>   google-public-dns-a.google.com.

You used a tool that returns a entry from the DNS.  That tool doesn't
do the reverse mapping into a hostname because it is a tool for querying
the DNS.  If you want a tool that deals with hostnames use something that
wraps getnameinfo().

> And you can use this rooted domain name get an A record:
> 
>   $ dig a google-public-dns-a.google.com. +short
>   8.8.8.8

Again you are confusing domain names with host names.

> As a matter of example, if you had automation that was internally
> testing your network for trusted certificates, and generated a set
> of hostnames based on reverse DNS, then your SSL client will now
> be using rooted domain names.
> 
> When I did my initial development with OpenSSL, I observed:
> 
> - If I did not have the rooted domain name in the SAN, then any SSL
>   client stack would fail the verification if a rooted domain name
>   was used to connect to the SSL server.

Well you have a broken SSL client app.  If it is accepting non legal
hostnames it should be normalising them before passing them to the ssl
layer.

> - I could generate a CSR with both formats of hostnames.
> 
> - My OpenSSL-based CA (and our internal MS-based CA) would sign
>   said certificate request, preserving all of the hostnames in the SAN.
> 
> - and now using a roted domain name was successful.
> 
> And I figured, if both OpenSSL and Microsoft's Certificate Services,
> (and their respective SSL clients) behaved the same way, I just
> coded my automated generation of the CSR to include the rooted
> domain names, just to cover my bases.
> 
> I did not expect that misc commercial entities would punish people
> under these circumstances...
> 
> Now, I expect in this specific customer's case, I'm reasonably
> certain that they won't have a tool chain / work flow / whatever,
> that would introduce a rooted domain name.
> 
> But, I don't know if I can guarantee that for all of our current
> and future clients.  I don't know if the practices suggested by RFC
> 1535 will come into effect, but I wanted to future-proof our product
> in this regard...
> 
> > 
> > Cheers,
> > -- jra
> > -- 
> > Jay R. Ashworth                  Baylink                       jra at baylink.
> com
> > Designer                     The Things I Think                       RFC 2
> 100
> > Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover 
> DII
> > St Petersburg FL USA               #natog                      +1 727 647 1
> 274
> > 
> 
> -- 
> Brian Reichert				<reichert at numachi.com>
> BSD admin/developer at large	
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org