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

From: Andrew Probert <[email-masked]>
Date: Wed, 3 Feb 1999 17:21:39 +1100

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.

It is at this point that the engineering complexity explodes with the Y.A.P.
principle i.e. lets invent yet another protocol, with attendant problems of
information and knowledge engineering.

The point of the X.500 protocols i.e. DSP, is that they have already got in
place the heavy engineering to route queries between the back-end servers (a
feature that even the ubiqutious Web servers do not have).  There are all
sorts of interesting feature like hop counters to ensure queries don't loop
around the world.  There are multi-cast features to ask all servers,
concurrently, do they have the items of interest.  The protocol is
extensible with regard to objects and their attributes and even to
supporting proprietary services.  There is strong authentication between end
users and the servers and servers to servers.

If the end point is to have an infrastructure for PKI that can route queries
between trusted servers, then in my opinion this can be achieved at a lower
development cost by extending a protocol and services that already exist,
using product implementations that already exist and have all of the
operational niceties like diagnositics and operational management built-in
(which is the next engineering issue after you get the protocols actually
working).

A *real* issue is percieved cost of development and not-invented-here
syndrome as a vendor can create a new protocol from scratch, at a perceived
lower entry cost rather than going up the learning curve on a richly
featured (downside complexity)
standard.

The alternative is that you see things like the LDAP API simplification,
followed by many iterations of versions to get it back to where the DAP
standard started years ago, with many $$$ of development burnt in the
process.

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171

> -----Original Message-----
> From:	Alan Lloyd [SMTP:[email-masked]]
> Sent:	Wednesday, February 03, 1999 12:28 PM
> To:	'Bob Jueneman'; [email-masked]; [email-masked]
> Cc:	[email-masked]
> Subject:	RE: FW: Attribute used to store cached certificate chains?
> 
> A comment
> 
> > -----Original Message-----
> > From:	Bob Jueneman 
> > Sent:	Wednesday, February 03, 1999 7:31 AM
> > To:	[email-masked]; [email-masked]
> > Cc:	[email-masked]
> > Subject:	Re: FW: Attribute used to store cached certificate
> > chains?
> > 
> 	snip
> 
> > In my view, the distinguishing characteristic that differentiates a
> > directory from
> > a repository is that a directory reflects a snapshot of a world-view
> > at a
> > more or less current instance in time, whereas a repository attempts
> > to
> > maintain a reliable historical record.
> > 
> 	A directory service - is a distributed information system which
> has an information doctrine. In terms of its characterisation by X.500 -
> it is object oriented, has an authentication and access control regime,
> has a common schema and information management model and offers both
> distribution and replication facilities in order to satisfy ownership
> and administration as well information service levels. A directory is a
> protected object oriented distributed name based transaction system
> which operates on knowledge.
> 	A repository may in its comercial implementation have some of
> the above features. However, I don see to many standards for
> "repositories". So they tend to be related to central storage /DB type
> systems.
> 	A directory service can be used as an archive. In fact the
> archive component can in fact be part of the DIB.
> 
> 	regards alan

---

From: Stephen Kent <[email-masked]>
Date: Thu, 4 Feb 1999 12:56:37 -0500

andrew,

>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.  We do this with web servers
quite well today, 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.

Steve