----- Original Message ----- > From: "Brian Reichert" <reich...@numachi.com>
> > 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. And there probably shouldn't be, and yes, you will probably have to have short names in there as altnames; there isn't -- and again, cannot be -- a rule for that; it's implementation dependent. > Who should implement the normalization logic? Not the SSL library, > certainly. That sounds like the bailiwick of the resolver library... No, in fact, I think this is layer... 3 or 4, not 2; this *should* be in the SSL library -- *you're not resolving this name*. > > 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. :) Pomegranates. Martha Stewart taught me over the weekend how to get the seeds out without ruining them. Cheers, -- jra -- Jay R. Ashworth Baylink j...@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