CDR: Re: Public Key Infrastructure: An Artifact...

Lynn.Wheeler at firstdata.com Lynn.Wheeler at firstdata.com
Thu Nov 23 11:17:10 PST 2000




Basically cetificates are an implementation of R/O partial replicated
distributed data that were intended to address availability of information in a
predominately offline environment.

In the SSL server certificates, distribution of CRLs tend to create a problem
for consumers because they aren't likely to want to see 99.99999999999999999999%
of the CRLs distributed and/or they aren't online at the time the CRLs are
distributed (and/or if done via email would create a horrible spam issue ...
every possible consumer in the world receiving email CRLs from every possile SSL
server certificate issuing CA).

The other solution is to go online and do real-time checks ... but doing
real-time checks invalidates basic design decision trade-offs associated with
choosing a R/O partial replicated distributed data implementation in the first
place.

A number of other efforts have looked at the trade-offs associated with large
distributed data implementations and have made various different implementation
decisions based on different criteria & requirements. Some  of the partially
replicated data implementations have gone to the trouble  if 1) truely offline,
R/O replicated data that has low change frequency, and possible adverse effects
of dealing with stale data is non-existent or 2) support R/W partial replicated
distributed data with various dictionary implemenations keeping track of the
"current" R/W owner.

However, in the case of both having R/O replicated distributed data and also
requiring online access ... creates a situation where the R/O replicated
distributed data implementation is redundant and superfulous (except in some
scenerios where the packet of R/O replicated distributed data is significantly
larger than the transaction to check on its staleness ... aka multi-megabyte
documents might be an example).

It isn't that you can't have perfect R/O replicated distributed data
implementation if there is also concurrent real-time access to the original data
... but that usually invalidates the design decisions trade-offs that justified
having a R/O replicated distributed data implemenation in the first place.

The degree of redundancy and superfulous becomes more significant as outlined in
the SSL server certificate case ... where 1) in large part SSL server
certificates are justified to address integrity weaknesses in the domain name
infrastructure, 2) SSL server certificate issuing agencies are dependent on the
domain name infrastructure as the authoritative source associated with proofing
information for issuing an SSL server certificate, 3) correcting integrity
weaknesses in the domain name infrastructure (needed by the SSL server
certrificate issuing agencies) by registering public keys with domains names, 4)
said registered public keys can both a) eliminate integrity weaknesses
justifying SSL server certificates and b) be distributed as part of domain name
server real time request to the client ... which then can be used in a much more
efficient SSL protocol implemenation.

A possibly better phrase is that in a large number of cases revokation isn't
practical w/o real-time access to the original data ... but real-time access to
the original data obsoletes the need for revokation (by obsoleting the necessity
for R/O partial data replication which might require revokation).

The issue in many scenerios  isn't that revokation can't work ... it can work if
you have real time access to the original data  ... which obsoletes the
requirement for R/O partial data replication which in turn obsoletes the
requirement for revoking R/O partial data replication. The ideal solution for
revokation is somehting of a catch-22 ... the ideal solution for revokation also
removes the requirement for revokation (somewhat analogous to the catch-22 for
solving the problem that SSL server certificate issuing agencies have with
domain name server infrastructure integrity issues ... the solution is also the
seed for obsoleting the need for issuing SSL server certificates).






Mark Scherling <mscherling at xcert.com> on 11/23/2000 09:24:51 AM



More information about the cypherpunks-legacy mailing list