RE: Major comments on OCSP (and LDAP Sec

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

In the interests of bandwidth I have removed the content of the original
message.

I want to go on holiday. Oh look, I have a bicycle and with my tools I
can add an engine. However, many people are coming so I will need more
bikes and engines.

I want to go on holiday. Oh look I can travel on a 747 with the other
people.

Same problem - different solution because of the solution space
available.


If one has a protocol- server- comms view of the world, any perceived
problem will be fixed by another protocol and another server.. As said
the more protocols and dedicated servers one adds to a system - the
higher the cost and human effort to deploy and the greater the chance of
hitting scaleability walls.

X.500 and X.509 go hand in hand (but ther are many who will argue that
X.509 can live without X.500 ? thats their choice.) I am sure that one
can take the engines off a 747 as well - but why.

Any way the ability to process information objects at any specific speed
in a distributed directory system is obviously tied to the underlying
protocols - and its the same rules here for SMTP, HTTP, DAP and LDAP. so
lets forget this area. The real issue is the distribution of the system
(ie its knowledge and the operation of interconnected DSAs and the
complexity of the objects themselves. In this case its CRLs.

In my opinion if there is an information and processing issue with CRLS
from an operational perspective. Then lets fix that. NOT add YAP (yet
another protocol)- because that is the old way of doing things - and the
wrong way if one is dealing with distributed object oriented systems
which have sufficient protocols to operate with.

For instance say we added functionality to CAs that optionally let them
plant "valid status" objects in their directory - that could be accessed
by the cert path processes - if these objects existed, then the problem
is solved. Same LDAP/DAP, DSP protocols, same directory system, its just
that it now has optimised information sets and path processing
capabilities. We would have had to do this info/process support for OCSP
in the CA and the directy anyway, but in this case we dont neeed OCSP as
another protocol or extra servers or much bigger clients. The problem is
fixed at the point of its weakness - ie. we are not adding more
complexity and introducing yet more problems.

Where I deal with large PKIs and this area looks like it might be a
performance issue. I will naturally recommend such an approach. Simply
because its simple flexible and solves and information processing issue
with an information processing solution.

However, I cannot stop those who want to keep inventing more protocols
and add complexity, cost, scaleability issues, risk and loss of trust,
etc-  to do so.

regards alan