Subject: RE: The case against directories

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 28 Mar 2003 06:53:11 -0800

> Yet another thread against directories. I wonder when "cases 
> against XML" will be issued after we have found yet another 
> new technology that markets well.

Actually the issue is not angle brackets or not, the issue is
the primary search key.

The only query that a PKI enabled application wants to make
is to map a network address to a public key. There is no
direct support for this in hierarchical directories - unless
you structure the DIT using DNS names and then you have DNS
in ASN.1.

SCVP can with modifications serve the exact same purpose as
XKMS and be equally useful.

In general it is simply not useful to have information that
is structured for both machine retrieval and human retrieval.

> As already has been stated, the problems are mostly 
> organizational than technical.

The technical issue is still substantial. There is no standard
query I can issue that is supported ALL by the DEPLOYED directories
that will allow me to do a lookup on the email address of the
person I want to contact.

Therefore there is no standard to do the thing that is useful.

> Even if you don't like it, directory supported PKI is being 
> more and more implemented. 

No it isn't. We deploy the PKI and then link it to the customer's
directory if they have one. The applications don't actually
interact with the PKI though so this does not meet any reasonable
definiton of 'directory supported'.

You can shut down the directory and degauss the hard drives and 
most PKIs will work exactly as well. Many will work better.

> Banks and other big companies are deploying directories for 
> PKI as well. Are all of them on a dead end road?

Ask if any of those banks intend to make their directory
accessible beyond the firewall. I think you will find the
answer is over my dead body.

> > 2. Internal information  (including employment) is 
> generally not public
> 
> No problem for directories, since you have well established 
> and good working authentication and access control 
> mechanisms, so everyone can define who is allowed to see the 
> certs.

Nobody trusts those mechanisms, nor should they. Even if 
the software is correct (doubtful even if it is advertised
as unbreakable) the configuration probably isn't.

We do managed security services as an outsourced service.
Quite often when we take over a customer's firewalls we
discover horrors. It is unusualbut not as unusual as it should
be to find that a $100,000 fault tolerant, redundant etc. 
firewall is being run with all trafic allowed in both directions.

> Yes, and as I said before, ther might be scenarios in which 
> XML/Web Services technology are more appropriate (I am not 
> making a "case against XML"). Still I know of a lot os 
> scenarios, where existing, well established technology is 
> better for production services.

We have tried X.500 for 15 years now with zero utility 
demonstrated with respect to PKI. LDAP has been arround for 
less time but there is no major architectural difference
except for the fact that once upon a time LDAP was simpler.

This reminds me of the arguments the physicists used to 
make for FORTRAN. It is tried technology, why move to
something that is newer, has been designed with a knowledge
of the architectural limitations of FORTRAN, a better 
understanding of program language design and which empirically
results in more accurate code with fewer bugs that is 
completed in much less time and is much more maintainable 
afterwards?

> > Unlike directory systems, SAML allows secure access to any kind
> > of active or passive information source, including purchasing and
> > work-flow systems.
> 
> SAML is a good but complex means for communicating 
> authorizations ans assertions, it is not a whole middleware 
> infrastructure.

Actually SAML is two things, the AAA application statements and
the assertion framework. The assertion framework absolutely is 
a middleware infrastructure and was designed as such. It is 
intended to be possible to support every X.509 signed data 
construct within that framework and in fact any other statement.

As Tim B-L pointed out the SAML assertion framework is a 
competitor to RDF.

		Phill

---

From: Michael Ströder <[email-masked]>
Date: Fri, 28 Mar 2003 17:42:09 +0000

> you structure the DIT using DNS names and then you have DNS

You did not read the quite concrete replies in the former thread thoroughly 
enough. IMO you don't *want* to read them. While pointing out real-world 
problems in e.g. LDAP your responses regarding the very same issues in 
name-your-favourite-buzz-word-technology-here are nothing more than 
marketing blurb. This has absolutely nothing to do with technology. That's 
just promoting your new gadget.

This behaviour is the real obstacle to PKI deployment because it confuses 
vendors who don't want to invest yet more money in yet another half-cooked 
blown-up PKI blurb technology. (Someone out there having a good translation 
of the german term "Investitionssicherheit"? Would be appropriate here.)

I'm not the one who is saying that LDAP/X.500 is *the* requirement for PKI 
deployment. I'm also no DIT fetishist. If you don't know how decouple 
directory DIT and certificate naming you have the wrong job. But having a 
PKI repository accessible via LDAP helps for quite a bunch of existing 
applications. name-your-favourite-buzz-word-technology-here are yet to be 
implemented.

I have no objection against other technology. But I'm really getting sick of 
yet another PKI "standard" which promises to solve the old problems but 
never will reach remarkable market share since the old problems aren't 
solved. If this is the business model of some PKI vendors they will fail in 
the long run. That's for sure.

Ciao, Michael.