Ram A Moskovitz <[EMAIL PROTECTED]> writes: > I tend to agree that the operator of a particular IA or CA is in the > best position to offer real time revocation services as they have > the primary data feed and would not have to rely on stale > information to provide status services. The IETF flavor of OCSP can > be profiled to retain the highly desireable cacheing features of the > pre OCSP status protocol such that one can tune the length of cache > validity to the applications so that in risk transactions (not > necessarily just financial I should point out) one can use real-time > status while for lower risk transactions one can use a longer cache > period and in that way maintain control of the balance between risk > and cost - this is a very useful capability when trying to manage > risk effeciently and effectively.
so in the FSTC FAST scenario http://www.fstc.org/ mentioned in the previous post http://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used instead of the end-user sending the merchant an digitally signed x9.59 transaction mapped into standard iso 8583 message network http://www.garlic.com/~lynn/8583flow.html which the relying party then sends off and gets an answer back from the authoritative agency (in the case of financial transaction, whether the merchant will be paid or not) ... a very similarly formated transaction of the same size and shape is sent off to ask any of possibly dozens of questions. furthermore, there is no attached redundant and superfluous digital certificate that results in two orders of magnitude payload bloat. another way of looking at it ... is rather than having a large PKI infrastructure targeted at efficiently providing information in a no-value and/or offline environment ... and then layering the overhead of an online transaction infrastructure over it .... there is just the overhead of the online transaction infrastructure. So the FAST scenario has at least all the transaction efficiencies of OCSP ... w/o any of the heavy duty, extraneous, redundant and superfluous burden of PKIs and digital certificates. The other way of looking at it ... was that OCSP was trying to emulate the online transaction efficiencies of FAST, but trying to maintain the facade that the stale, static, redundant and superfluous PKI digital certificates were in anyway useful (for such an online environment). To meet that requirement (maintaining the fiction that digital certificates were useful in such environments), OCSP was limiting itself to a transaction about whether the information in a specific stale, static, redundant and superfluous digital certificate was still valid. The FAST scenario just did a highly efficient, straight-through processing digitally signed transaction to get a reply about the actual information (somewhat riding the existing rails that providing highly efficient straight through processing for performing payment transaction). If OCSP starting expanding its horizion and asking real live questions (aka turn into something more akin to FAST) ... then it would become more readily apparent that the stale, static, redundant and superfluous digital certificates weren't serving any useful purpose. -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
