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

From: Stephen Kent <[email-masked]>
Date: Wed, 4 Nov 1998 18:21:11 -0500

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: [email-masked]
Date: Thu, 5 Nov 1998 10:22:06 -0800

i've stated that if an account record has to be accessed in order to
complete the operation/transaction ..... then the certificate portion is
superfulous.

As mentioned elsewhere, certificates have been characterized as originating
to provide similar attribute/authentication binding in the offline world as
has been available in the online, account-based world (the certificates
don't do the authentication ... the certificates provide the binding
between attributes and public-key so that the authentication can be done
... i.e. enabling authentication capability similar to what is provided by
accounts in the online world).

Trying to then retrofit such an offline binding capability to the online
world ... where the binding capability has already existing ... is
superfolous, tends to unncessarily increase risk and complexity while
reducing availability.

---

From: [email-masked]
Date: Thu, 5 Nov 1998 11:50:39 -0800

one account attribute is the account balance in your bank account. would a
attribute certificate be re-issued and the previous one(s) invalidated
everytime the account balance changed. would you present an account balance
attribute certificate everytime you executed a financial transactions.
would a new CRL have to be sent out to all parties that you might possibly
ever do a financial transaction with everytime the value in your bank
account changed (either increased or decreased). Could you imagine an
optimization where you only sent out a CRL for decreases ... and not
necessarily for increases. What would be the protocol between you, your
bank, and the CA for issuing new validated attribute certificates everytime
your bank account changed. Because of privacy concerns are you really
interested in broadcasting your current account balance in an attribute
certificate on every financial transaction?

---

From: [email-masked]
Date: Fri, 6 Nov 1998 09:18:54 -0800

there are financial infrastructures that have much higher integrity than
any of the CAs or public key infrastructures (i.e. spending past six years
getting to the point where there is no down time).
When my wife & I were running skunk works in the 80s doing high speed data
transport & high availability product  ... i coined the term disaster
servivability (to distinquish from disaster recovery ... requiring hot
operation with geographic seperation).

Part of insuring the integrity of a financial transaction is having access
to being able to complete every transaction. Places have gone to the point
of guarentee that all information is available in a single place for the
completion of the transaction .... bunkering that single place with
no-single-point-of-failure iredundancy and UPS with diesel back-up; and
then replicating the facility at two additional bunkered sites (any single
system at any single site is sufficient to complete the transaction).

Having transaction completion dependency on any offiste data/function
lowers the integrity ....
availability is the product of all the availability numbers for all things
that must be available for the completion .... redundant availability is
one minus the product of the non-availability numbers.
The financial redundent single site availability number might be five nines
(.99999). Triple redendant geographic survivability then would be
1-(.00001*.00001*.00001). Not having all information stored at each site
necessary to complete the transaction .... implies that at least two sites
have to be operational ... as well as the communication path between them.
The financial infrastructure has availability number of
1-(.00001*.00001*.00001). The communication path ... even with diverse
routing might be three nines (.999) and the 2nd site mght be four nines
(.9999).

The resulting availability for non-single-site-stored-data then is
something like:
                 (1-(.00001*.00001*.00001))*.999*.9999

that can be easily shown to be less than .9999 (since it is the product of
numbers that are all less than one ... and at least one of the numbers is
.9999 or less) ... which was the original unacceptable number for (at least
some) financial infrastructure which prompted the original triple bunkered
site with geographic dispersement in the first place.

The alternative model to reach this level of availability w/o requiring
geographic redundancy with the single-site data model .... is the
simulation of some ECC/FEC possibly R/S 64/80 where all eighty sites have
independent failure modes (some mainframe memory subsystems do 64/80 ECC).
Small problem is resync'ing sites when some have been offline and their
information becomes stale (this is problem in the three site replication
also .... but is somewhat easier with three ... than it would be with
eighty).

In any case, just saying a CA &/or independent certificate directory has
high availability support with no-single-point-of-failure  .... doesn't
necessarily show the whole scope of the issue. Taking an existing operation
that has effectively single-site completion dependency (or even redundnat
single-site completion architecture) ... and move to non-single-site
completion paradigm ... involves (at least) the local site, the
communication modes between the sites, and the 2nd site.

There are also issues of partitioning and locality specific failure modes.
An ISP might cover a geographic locality and provides redundancy to handle
availability levels up to major geogrpahic specific outages .... but
doesn't want to be subject to outages outside local geographic area (i.e.
ISP in california would survive everything up to major earthquake in
california ... but doesn't have to survive a local major earthquake since
all of the
customers would be down also). ISPs with geographic locality coverage only
has to
survive failure  modes that the majority of their customers would also
survive. National or
international ISPs can create gegraphic centered service centers to take
advantage of geographic nature of some failure modes. This gets into an
area of failure mode management
slightly different from the raw statisticaly distribution probability mode
of handling failures.