Subject: RE: Lookup from DNS was: X.500, LDAP Considered harmful

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 28 Jan 2003 08:17:30 -0800

> My main concern was that you'd end up mandating something 
> that would be impossible to do for 99% of the user base, 

That does not actually affect XKMS. If you can't use SRV on
your box you can delegate the query to a box that does have 
SRV support with an XKMS locate or validate service set up.

The only reason you would need local support for XKMS would
be if you wanted to use SRV to support auto-config on the
client so the client can automatically discover its local
XKMS information and registration servers. That is a neat
trick, but it is absolutely not a 'must have' issue.

SRV is supported by all the current versions of Microsoft 
Windows so we don't need to talk about 99% being unable
to use it.

In Windows the cryptographic subsystem is part of the O/S so
any extension of that system is going to require an O/S upgrade,
either a new O/S version or a service pack. So any upgrade that
allows following of SRV pointers can make any necessary fixes
to the DNS stack at the same time.

The DNS stack can be supported at the client layer in any case.
This is what all the early W95 browsers did.

The only real constraint is that the enterprise DNS system has
to support SRV records at least at the level of forwarding 
queries.

I agree that there may be legacy issues here. I don't think that
they are important as the worst that happens is that you are only
able to use the existing infrastructure which as we all agree (apart
from the directory vendor) does not work for PKI anyway.

		Phill

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 29 Jan 2003 15:13:50 +1300

>Windows so we don't need to talk about 99% being unable

Well, if by "all the current versions of Microsoft Windows" you mean
"Windows XP" then I agree with you, however it still only gives you
what, 10%? 15%? coverage (I don't know what the user base for XP is,
but the machine I'm using at the moment, for example, is still 
running NT4 (there are all sorts of weird old boxes here), so it's
going to be awhile before you can just assume handling of SRV).

>This is what all the early W95 browsers did.

That's the Win3.1 approach.  Everyone who's ever used TCP/IP under
Win3.1 knows how well that worked.

Peter.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 29 Jan 2003 08:42:44 -0800

> going to be awhile before you can just assume handling of SRV).

Are you saying there is a problem with the W2K stack? I was under the
impression that SRV was what kept most of the W2K systems hanging
together.

> Win3.1 knows how well that worked.

Yes, yes, it is still not a show stopper. If you are running on a 
system that does not support SRV you can delegate to a Locate or
validate server that does the work for you.

You need that capability in any case if you hope to build cross
certification paths reliably through the bridge CA. [If you don't
believe me explain how to find a path through the Canadian bridge
through the FBCA to the HEBCA bridge efficiently using X.500 lookups
alone]

I don't think that the problems with Win3.1 TCP/IP were due to people
reimplementing the stack themselves.

		Phill

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 30 Jan 2003 17:50:33 +1300

"Hallam-Baker, Phillip" <[email-masked]> writes:

>Are you saying there is a problem with the W2K stack? 

WinLibResolv (or whatever MS calls it) wasn't stable until XP.

>I was under the impression that SRV was what kept most of the W2K systems
>hanging together.

The goop that keeps 'em going is really WINS (NetBIOS) and AD, not SRV.

I've been trying to find out more about what it'd take to do SRV under
Windows, apparently the WinLibResolv stuff was needed for AD and was added in
bits and pieces under Win2K, but the (stable) API wasn't exposed until XP (you
can find it in various forms under 2K, but can't really rely on it). 

libresovl should be portable to Windows (there's also the cygwin version
obviously), but to get things to work properly you generally need to use the
Windows sockets extensions, and even with a fully ported libresolv you don't
get WINS and AD tied in, which may be how the environment you're working in
happens to do things.  You could use something like adns (which is LGPLd and
safe to use), but that's just a libresolv port, is only a stub resolver,
doesn't do Win95, and doesn't appear to do SRV (anyone have any more
experience with this one?  I was tempted to use that, but didn't want to spend
ages messing around with something that might or might not work out in the
end).

Even with a bolt-on resolver, you still get, well, a bolt-on resolver.  From a
recent thread on the secprog list:

  That's probably one reason why people still keep using only libc stuff -
  requiring external libraries is annoying, distributing huge <new-capability>
  libraries with your sources is annoying, and stripping them down to bare
  minimals is also annoying.

Disclaimer: I'm not a libresolv-under-Windows expert, this is just what I got
by asking around (which got warnings like "DNS is a mess, and it's difficult
to produce a foolproof resolver implementation. a braindead one is simple,
sort of like anyone can do a simple MTA, but then look at what sendmail has to
do...", which is why I'd prefer to use the OS built-in implementation since
I'll be at least bug-compatible with the system's normal behaviour), and from
playing with it some months ago when I was working on the certs-over-HTTP
draft.

Peter.