Re (subtopic): LDAP certificate distribution

[Steve Hole <[e-mail]>]

On Thu, 14 Aug 2003 19:58:11 -0700 Julien Pierre <[e-mail]> 
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
>  > [e-mail] 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:[e-mail]>
Phone: [phone]