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

From: [email-masked]
Date: Mon, 26 Oct 1998 11:16:22 -0800

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)

---

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Mon, 26 Oct 1998 16:25:26 -0500

> has to be two things that are operational for transaction completion

I would not propose such a split. In fact I think it argues to my point.

Perhaps I have been unclear, the functional division I see as essential
is at a somewhat abstract level. I want to avoid bluring the distinctions
between PKI functions and information distribution functions precisely
so that applications such as Lynn's can be supported.

You want the authentication information from the PKI to directly mesh
into the authorization information supplied by your application.

In other words you do not want to have a directory intermediating
between the PKI and your application.

The question to ask is 'what box (program etc.) have I just added
that can break?'

If there is a per-transaction protocol connection required for PKI
use, it will as you said reduce your availability. But PKI is not
inherently protocol oriented. Nor is it necessarily a 'box to
break'. It would be more accurate to view being 'PKI aware' as being
a quality of systems rather than "THE PKI" being a discrete system
in its own right that can be pointed out in the control room and
thumped with a hammer when it breaks:-)

In other words the PKI should not mandate a 'coherent directory
infrastructure' since the PKI abstraction should not care how the
bits arrived so long as they are properly signed. But what the PKI
suite of standards MUST do is to state how to link to a directory
to obtain such information in the case where one is available.

To permit scale your PKI protocol infrastructure needs to be entirely
integrated within your transaction protocol infrastructure - at least
for that *particular* application. That does not mean however that
there is no 'PKI' component or indeed that every piece of the
infrastructure must be integrated at that level - certificate
issue could well be independent.

A good reason to be ruthless when insisting on separation of function!
It is very easy to propose tweaks that look very good in a limited
context but fail in a larger one.

		Phill

[PS OK I'll admit that it is much the same once you get up to Terabytes
of data but I was talking about input bandwidth, not just static
storage :-) I think that you Steve and myself are essentially arguing
the same point though.]