RE: Major comments on OCSP (and LDAP Sec

>----------
>From: Alan.Lloyd@xxxxxxxxxxxxxxxxxxx
>To: carlisle.adams@xxxxxxxxxxx; ambarish@xxxxxxxxxxxx
>Cc: Graham Bland; ietf-pkix@xxxxxxx
>Subject: RE: Major comments on OCSP (and LDAP Sec
>Date: 13 August 1998 20:37
>
>
>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.

If one requires a cheap glider why should one be required to fit 747 
engines.  It moves the compelxity and cost out of reach of the purchaser.

A large number of messaging protocols allow the distribution of certificates 
(and CRLs) with the message.  These can work perfectly well without 
directory support.

I completely agree that for a large PKI infrastructure a directory is 
essential.

>
>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.

To summarise you are suggesting:

1 )The CA adds a (presumably signed) object into the directory for every 
certificate stating it is valid when a certificate is issued.
2) The CA informs users of the certificate that it is invalid by deleting 
the object from the directory.

As a simplification the certificte itself is a signed object, why not forget 
revocation and have the CA delete the certificate from the directory when it 
is revoked.  That would work just as well !!!!

>
>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.

But it doesn't solve the security problems.

>
>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
>

There are
Graham
--
Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK
Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
Website:  http://www.zergo.com