On Thu, 14 Aug 2003 19:58:11 -0700 Julien Pierre
<jpierre(_at_)netscape(_dot_)com>
wrote:
Why ?
Because you have to run a root. That is, the hierarchy has to have a top
level interconnect. This quickly becomes an issue of governance.
National goverments get involved the way they got involved in DNS. The
difference is that the governments got involved *before* the service was
running, not after the way they did with DNS.
There is a long track record of attempts at establishing global X.500
whitepages services. There were several attempts that I participated in
that just didn't gain traction. I think in retrospect it was primarily a
cost issue again. The *business* people and organizations who had
interest in participating couldn't stomach a "build it an they will come"
approach when there were real costs and somewhat amorphous benefits.
People just don't get why you need it and the formal delegation and
governance rules made it non-trivial to set up.
Note that I said "Whitepages". Regrettably, PKI information at the
global level was always linked to other personal information that would
aid in the search and retrieval of useful information on people. This
was a goal that I happily promoted and thought "was a great idea".
Wrong. What I (and many others) never thought about was the privacy
concerns. Sure the system is secure and access controlled etc etc. But,
the governance issues around actually making this information available on
the Internet was really huge. By the time some of this was figured out,
the perception had become that none of it was truly deployable. Very few
commercial organizations (government doesn't count) wanted that
information available and didn't believe that secure interpersonal email
(the one obvious use application) needed that level of support.
There were some not insubstantial technical hurdles with root management
and scaling as well. Problems that probably could have been (and were
for the most part) solved, but took long enough to solve that
people just didn't believe. Basically, there was enough disinterest that
the whole thing just stagnated.
Finally, the one thing that could have driven the service -- storage of
keys -- was itself a substantial cost item because of the cost of
certification. While certification costs have dropped, in the beginning
they were excruciating and only the richest could play. Therefore, there
never was a groundswell of use that demanded that the "situation be
improved". You need a Web like uptake to get the necessary
infrastructure allocated and serviced.
In short there was always a substantial cost. My experience with the
Internet is that the only things that successfully deploy to Internet
scale are things that start with the groundswell of the common user. It
has to be easy and it has to be (near) free.
> There is only one choice -- DNS. I (and Steve Kille and others) have
> been flogging LDAP directories and working on LDAP/X.500 interconnects
> for
> a decade. Global X.500/LDAP isn't going to happen in our lifetime.
Can you summarize why ?
Pretty much did above :-)
For what it's worth, I am NOT saying "LDAP is useless". What I'm saying
is that you need to leverage the one and only global directory service the
Internet is ever likely to successfully deploy to get to your LDAP (or
XKMS) services. Then we avoid the governance, root and cost issues
associated with global directory whitepages.
> Precisely. They must be able to do a DNS lookup for the information
> either as a direct data return or a reference to a secondary storage
> service, which absolutely could and probably should be LDAP. To
> work in practice I think that it should be possible to get a direct pull
> from the DNS so that organizations are not required to deploy an LDAP
> directory and all that goes along with it (much as that pains me).
I think other people have pointed out that DNS itself is not suited as
the repository for the certificates.
Since the query starts with only the e-mail address, which contains a
userid and domain, I think it is appropriate to start the lookup in the
DNS. There should be a standard schema to get to the appropriate LDAP
server from the user's e-mail domain. The certificate would then be
looked up from it. The client application could also fall back to a
"default" LDAP server if the DNS query fails to find the appropriate
directory.
Works for me. More LDAP servers sold then :-)
> The worst that can happen is that don't find the cert your looking for.
> Trust issues MUST be dealt with, but certificate trust chains and
> approaches are both well understood.
>
> The best that can happen is that suddenly I can go and find a cert for
> joe(_at_)foobar(_dot_)com with a simple DNS query. BEAUTIFUL! Why
wouldn't I want
> to do that?
Sounds good, but we have to make sure this is deployable for a lot of
people. I don't really see how it would be.
If LDAP is used to store the certs, perhaps all a domain owner might
have to do would be do add an entry in the DNS, either with a new record
type, or even simpler for quicker deployment, a standard name, eg
pki-public-ldap . This entry could be pointed to some free public
directory if the ISP doesn't want to run it itself.
I think we are in agreement. That was easy :-)
As noted in other messages the practical hurdles for deployment center on
management (key issuer) and client (user). Unless something is specified
there is no hope of even getting to those hurdles though.
Cheers.
---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:holes(_at_)ACIWorldwide(_dot_)com>
Phone: 780-424-4922