OCSP only tells you whether the certificate information is valid or not. lets say it is a financial transaction.
the financial transaction wants to know the current balance or credit limit (which is a real-time aggregated amount .... i.e. some previous value plus all transactions todate). so in a certificate world ... we put the current bank amount and/or current credit limit in the certificate (ignore for the moment the privacy issues). the merchant gets the certificate ... and then does the OCSP .... which is the chance the current, real-time value is in any way related to the stale value deposited in the credential. So we now have progress: we can do away with the credential all together ... and always just do the OCSP ... and the OCSP doesn't actually have to say what the current credit or balance is ... it just has to say whether the transaction is approved or not (addressing some serious privacy issues in placing current balance/limit in a certificate which gets broadcast all over the world). now it turns out we can call this new kind of OCSP transactions an ISO8583, X9.59 digital signed transactions for all financial transactions. The actual problem is that information about whether you are entitled to perform an operation (aka you are the actual owner of the account) which is a only small subset of the information of interest in performing a financial transactions. In fact, almost all merchants from the standpoint of a financial transactions ... don't give a darn about who you are (which is typically the information carried in a privacy-invasive identity certificate) ... but want to know whether they are going to get paid. Knowing that they are going to get paid is of significant more interest than knowing who you are. Knowing who you are can actually be considered irrelevent in a 8583/x959 financial transaction. If a merchant was given a choice of doing either 1) do an OCSP transaction to find out if you are still who you are or 2) do a iso8583/x959 transaction to find out if they are going to get paid Which do you believe a merchant will choose ... finding out if you are still you ... or finding out if they are going to get paid? So with a little simplification, we have now eliminated all transactions that involve financial matters. So what other transactions of value do you have in mind where: 1) the information in the certificate is totally sufficient by itself ... w/o any additional recourse, for supporting the business operation 2) there is no privacy issues when the necessary and sufficient information by itself is broadcast all over the world. For long detailed discussion of SLL web domain name server certificates business: http://www.garlic.com/~lynn/subtopic.html#sslcerts There have been all sorts of temporary market niches in the internet world that doesn't necessarily actually represent a sound, fundamental. longterm viable business proposition. Summary of the above: 1) SSL domain name server certificates invented to address integrity concerns/exposures with the domain name infrastructure http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 2) SSL domain name server certificates were quick&dirty fix to those integrity issues pending fixes for the basic infrastrucutre 3) Even then the basic business premise is flawed since the certification authorities are dependent on the domain name infrastructure as the authoritative agency regarding who owns a domain name 4) The irony is that the certification authority business has proposals to improve the integrity of the domain name infrastructure ... so that they can trust the information they are certifying as to who owns as domain name 5) Improving the integrity of the domain name infrastructure (for purposes of the certification authority business to trust) then starts the slippery slope invalidating the original premise for having the certificates in the first place. I've replayed this discussions tens if not hundreds of times .... SSL domain name certificates (which we were somewhat involved in as per refs in #1 above when as part of enabling this thing called electronic commerce for doing financial transactions ... my wife and i had to perform due dilligence several of the major certification authorities) are a quick & dirty fix to a online business integrity issue. Fixing that online business integrity issue ... eliminates the need for the offline certificates. Furthermore, there is some irony that the certification authorities are pushing fixing integrity business issues because they are also dependent on the same institutions for the validity of the information that they are certifying. I would, in fact, claim that the existanfe of the SSL domain name certificate business ... supports the contention that it is a market niche pending having the real online business ... aka in this particular scenario the real online business exists and has for some time ... it just is that there have been integrity issues ... and as soon as the integrity issues for the online business processes are fixed then the need for the SSL domain name certificate quick&dirty fix goes away. In fact the SSL domain name certificate business is pushing those fixes because they need it or there is then trust issues with the information they are certifying. They can do all the certification they want ... but if the source of the information is bad .... what they have certified is bad. [EMAIL PROTECTED] on 12/28/2002 9:49 am wrote: VeriSign's 500 000 Web-server certificates/year seems to contradict the statement that there is no money in TTP-issued credentials. One can argue about the quality of this but not the money :-) Using OCSP, off-line "stale" credentials becomes "live" and on-line. The alternative, having a unique credential at each resource provider is ineffective and slows down the use of "e-services". The real problem is that no matter what system you use, there is a risk that the person in the other end is not the one it should be due to credential theft, loss and to some extent due to CA errors. /a
