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 on 11/23/2000 09:24:51 AM