Subject: RE: OFF TOPIC ???? RE: Relational vs Directory Repository Models (was RE: pathdevelopment complexity s)

From: Alan Lloyd <[email-masked]>
Date: Wed, 9 Sep 1998 19:22:02 +1000

Thanks for the reply - comments in line. 

----------
From: Phillip M Hallam-Baker
To: Mike Smith; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Sent: 9/9/98 1:50:46 AM
Subject: OFF TOPIC ???? RE: Relational vs Directory Repository Models
(was RE: pathdevelopment complexity s)

Ph: I'm having a lot of trouble following this discussion. It appears to
have begun a discussion of the relative merits of X.500 vs LDAP server
models.
This does not appear to be something which is relevant to PKIX.
LDAP is merely a protocol. It does not define a product. Arguments based
on the 'scalability' of a client-server protocol are almost without
exception irrelevant since scaling depends on server-server
communication. The idea that the same protocol should serve both
purposes is questionable at best.

alan: LDAP is just a protocol! That statement is curious given that
features in protocol impact the system services that are conveyed to
and available from " the protocol". eg. Replicated/Master certfificates
.. How does LDAP get the Master copy of a certficate when it needs that.
If the certficate happens to be outside the "domain of interest" how
does LDAP control the extent of a search re Chaining.. It can not. If
one is trying to build large scale certficate based systems supported by
directory services, then "the protocol" used will affect the trust and
performance of the system services applied.. LDAP does not deal with
distributed systems - it deals with client interfaces to seperate
servers. Cert Matching Rules and LDAP (non X.500)servers? - ask the
vendors.

Ph:I fail to see how improved search capabilities will greatly assist
for the purposes of PKIX unless the directories have the ability to
break open, readand understand attributes embedded in certificates. If
people believe that support for a specific (and specified) search
mechanism would lead to an improvement in efficiency that is important
to PKIX let us discuss thatspecific extension.

alan: See X.500/9 certficate matching rules, see the draft I posted last
week. Cert and CRL matching rules can, in fact are intended to assist
the management and validation of certificates. They should be applied to
this end. As said in my draft, it seems pointless trying to get a client
to understand all the information and revocation designs of any CA that
might exist on this planet.
X.509 is part of X.500 and the application of X.509 to be scaleable
depends on the use and features of a directory services. The emphasis to
date on CA design has been.. information objects for CA functions that
"may" use a directory.
OCSP is symptomatic of this approach ie. no directory service is
considered. This = special client software and special servers and
special CA databases. Hardly an approach for the large scale of the
internet, the use of distributed, scaleable EC services and simple
clients.

To build a generalised, efficient, scaleable certificate infrastructure,
X.500 directory systems (not LDAP servers) are fundamental. With added
matching rules and common CA information doctrines (as applied to their
DIBs) the PKIX problem is very solveable.

Ph: We need to remember that we are charterted as an IETF working group
and weare not in a position to endorse a particular directory strategy.

alan: Well if "we" are chartered to build a car and it wants to be used,
by definition should we not be making sure that the roads and wheels are
in place. (eg directory systems). ie. when anything is designed,
assumptions or statements about underlying (scaleable) services should
be made.

Ph: If we want to be able to offload client work to a server of some
kind we should first consider the requirements that motivate such an
architectural approach and the trust implications of doing so before
considering protocol extensions. Indeed a critical step would be
deciding which protocol to base an implementation on.

Alan: X.500 was designed to deal with this issue (see X.500 1993 cert
and CRL matching rules).
There is no direct extension to the protocol" its the addition of convey
service requirements and modified directory matching rule support.

As for trust - then there is no trust in multitudes of chaotic CA
information designs and complex clients that cannot verify certs for
specific application and originator/recipient contexts.

Finally - it seems a lot of the work on PKIX has been made so complex
because of the limitations in LDAP, LDAP servers and "non directory
system" application, eg OCSP, eg, . Taking X.500 infrastructure away
from X.509 is like taking the wheels off a car and then trying to fix
the car's resulting problems.

So IMHO - if the charter of this group is to build a certficate
infrastructure for the internet - should we not follow industry trends
with directories ie LDAP or DAP access to X.500 that incorporates X.509?

And extend this as per dir-cert-stat draft to make it scaleable and
efficient.

Thoughts are welcome.

regards alan

		Phill