RE: Major comments on OCSP (and LDAP Sec

Comments in line.

> -----Original Message-----
> From: Graham Bland [SMTP:gbland@xxxxxxxxx]
> Sent: Wednesday, 19 August 1998 3:40
> To:   ietf-pkix@xxxxxxx
> Subject:      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.
        [Alan Lloyd]  
        I bet if one looked at the cost of the server function and the
protocols of OCSP plus all the scaling impediments and key management
issues that go with it . a directory would be a cheaper and more
sensible solution.

> A large number of messaging protocols allow the distribution of
> certificates 
> (and CRLs) with the message.  These can work perfectly well without 
> directory support.
        [Alan Lloyd]  
        But where do these Certs and CRLs reside - they cannot always be
in transit in the messaging protocols.


        I am afraid I do not understand the ideology of making very
complex, small contained systems with lots and lots of messages and
protocols and complex client software.. I tend to work in designing very
large scaleable systems with less complexity - and that is generally why
they are large.. :-)

> I completely agree that for a large PKI infrastructure a directory is 
> essential.
        [Alan Lloyd]  Why does any one want a small PKI - are we
talkning of 1-100 users here?
>  >
> >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 !!!!
        [Alan Lloyd]  
        Whats your idea then, A server inspects what the CA (which ones
and and where ????TBA) does and then stores the cert validity object in
its database so that at some time later a random client with Yet Another
Protocol (YAP) comes looking for it.. I think what you suggest I do is
still a lot simpler than what OCSP does.

        ie Information processing solutions are good for information
processing problems .


        OCSP seems to be saying - we have a car with faulty guages on
the dashboard - they are complex to read.. and the solution is... put
some more wheels on the car! (more protocol).

> >
> >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.
        [Alan Lloyd]  We shall see.
        But if one does have a directory system with a CA, rather than
one without a directory system - then the way one deals with problems is
a lot different. ie a 747 with engines is easier to get of the ground
than one without.
        [Alan Lloyd]  
        more regards alan
> >
> >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