----- Original Message -----
From: "Brian Reichert" <reichert@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 jra@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