Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])

From: Alan Lloyd <[email-masked]>
Date: Thu, 5 Nov 1998 16:26:51 +1100

Steve I think the response missed the issue. The issue Lynn describes is
one of optimising information management and keeping all things
pertinent to a User in one place (inc its certs) and that over a
distributed business, different users will be stored in different
places. Its not a question of "real time" because directories can be
real time, thats sizing. Its not a question of caching, because the data
has to come from somewhere in the first place. 
 The common approach to User and user authentication is a single record
- in a distributed "data store" - a directory system  and that a CA
directory is part of the directory cloud and that User entries have User
certs in for authentication.
 IMHO Its the information management and administration optimisation
that drive the directory requirements for the larger organisations.

regards alan

> -----Original Message-----
> From:	Stephen Kent [SMTP:[email-masked]]
> Sent:	Thursday, 5 November 1998 10:21
> To:	[email-masked]
> Cc:	Phillip M Hallam-Baker; Alan Lloyd; Al Arsenault;
> [email-masked]
> Subject:	RE: A different architecture? (was Re: certificate path
> services 	[ was RE: NEW Data type for certificate selection ? ])
> 
> Lynn,
> 
> >there are business operations with account-based systems with
> >100million
> >entries and raw
> >data in tens of terabytes. for business process that have to access
> the
> >account record to complete the transaction, splitting responsibility
> for
> >the transaction between an account infrastructure and a PKI
> infrastructure
> >... doesn't improve availability ... it actually lowers it since now
> there
> >has to be two things that are operational for transaction completion
> i.e.
> >availability to complete is the product of the availability of the
> two
> >infrastructures; for availability to improve, transaction would have
> to be
> >able to complete even if the whole PKI infrastructure or the whole
> account
> >infrastructure was not operational (and since the original premise
> was that
> >at least the account infrastructure has to be operational for the
> >transaction to complete; adding a PKI infrastructure can't improve
> the
> >availibitliy)
> 
> I agree with the overall observation, but note that for many of these
> sorts
> of applications, realtime exchange of certs and CRLs, and/or caching,
> may
> obviate the need for realtime directory access and thus remove the
> availability concern you cite here.
> 
> Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 5 Nov 1998 07:47:42 -0500

Alan,

>that drive the directory requirements for the larger organisations.

Not surprizingly, we again disagree.  The issue of realtime IS relevant
here because in such applications (vs. e-mail, for example) the
communicating peers can exchange cert and CRL data directly.  In contrast,
applications such as e-mail require one party to retrieve cert and CRL data
prior to communication.  That's the point I was making.  Also, it IS a
matter of caching because caching provides performamce improvements, an
issue in realtime apps, not so much so in stanged deliver apps.

The common approach you cite for user auth is valid, but the CA is NOT
intrinsically part of the directory.  It is just a subscriber to the
directory, just like the users.

Steve