RE: FW: Attribute used to store cached certificate chains?

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

Comments in line

> -----Original Message-----
> From:	Stephen Kent 
> Sent:	Friday, February 05, 1999 4:57 AM
> To:	Andrew Probert
> Cc:	'Alan Lloyd'; 'Bob Jueneman'; kent@bbn.com; WHenry@pec.com;
> ietf-pkix@imc.org
> Subject:	RE: FW: Attribute used to store cached certificate
> chains?
> 
> andrew,
> 
> >I think a re-statement and perhaps some may think oversimplification
> of the
> >case is as follows: -
> >
> >CRLs are a batch method for publishing CRLs and we are agreed that an
> online
> >realtime mechanism is required.
> >A client navigating to a single OCSP server looks ok.
> >When there are myriad of OCSP servers, the job becomes far more
> complex.
> >A rationalisation of this is to have a single OCSP server that via
> backend
> >protocols talks to other OCSP servers on the users behalf.
> 
> I can put the name of one OCSP server into a cert and have many
> instances
> of that server available, for reliability.  
	But this means that the OCSP servers need to share the same data
and information sets ie replication is needed > In addition OCSP servers
may wish to do contextual/policy verification - based on locality/value
transaction originator.
	So I think there is a bit more to it than saying a URL to
multiple OCSP servers is OK. Before one says that we need to understand
contexts, policies and information management issues.


> We do this with web servers
> quite well today, 
	These are much simpler that cert validation in a business
transaction context.

> so this is not an unsolvable problem.  Also, having lots
> of OCSP servers is not intrinsically a problem; the problem you cite
> seems
> to arise only when a given cert might be checked by many independent
> servers.  I've not seen compelling arguments suggesting why such an
> arrangement is needed.
> 
	I have a few views about this.

	regards alan
> Steve