On 01 Jul 2005 14:30:05 -0600, Anne & Lynn Wheeler <
[EMAIL PROTECTED]> wrote:
It did. We developed a real-time method for checking the validity of certificates. The advantages of having real time status services are described in many of your posts usually in the context of the credit card industry; status services can be useful when trying to address privacy concerns and reputations as well as managing authorization for installation or execution of software - you tend to label these types of applications as "low value" or "no value."
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.
I think it's worth noting that for a particular application one could, in a competitive market with multiple providers, compare the policy of various SPs to compare their ability and willingness to offer higher sensitivity status services (small cache time to live) as in indication of exposure when relying on their services just as one could compare authentication policy to the same end. Consider further that some CAs could not qualify their public services under various US government regulations, and indeed are not approved to issue certificates under those regulations in various US states, nor meet the recommendations of various expert groups including ISO and the ABA ISC but instead tend to cite minimal WebTrust accreditation which is primarily targetted at having CAs reveal their practices and not so much specify what those practices should be (which WebTrust provides guidenace through examples but does not require for their 'certiffcation').
At the heart of these matters is an evaluation of proper policy, this is theoretically the discussion of the maligned private discussions between some of the browser / OS / and CA service providers out there. In theory that group will go public with a set of recommendations that are compatible with the existing US regulations and various specification group recommendations that many in the public CA space do not meet under their current practices. Presumably at that time the browser providers will have to scrub their root lists to eliminate the weaker players or maybe the weaker players will overhaul their practices to comply with existing regulation and practice.
It is unfortunate that as a society we know how to value financial transactions and defend against them but the mechanisms for individual privacy protection are not as well represented. One can the credit card industry evolving lock step with fraud as they release new mechanisms for protecting themselves (mostly protecting the banks than the merchants who essentially buy insurance from the various bank and financial network operators). One can see in other environments where this happens; consider the the wireless network bandwidth owners continue to take measures to protect their resources by increasing the tools they have for managing what content is executed on their platforms which could be stealing bandwidth by using network resources without the users approval (generally this is done by using CA services).
Given that individiaul privacy doesn't have a directly measurable value to a business there is not the same motivation to protect it and so most individuals rely on the various community participants to do the right thing which, given the long feedback loop, is taking longer than many of us would want.
cordially,
ram
OCSP sort of came on the scene in the mid-90s after I was pointing out
that suggestions regarding converting the payment card network to
"modern" PKI was actually a technology regression of 20 or more years.
Ram A Moskovitz <[EMAIL PROTECTED]> writes:
> Are you sure OCSP didn't come out of the IETF as an effort to
> 'standardize' the VeriSign / Microsoft certificate status service
> that was launched as an extension to ActiveX?
it may have
It did. We developed a real-time method for checking the validity of certificates. The advantages of having real time status services are described in many of your posts usually in the context of the credit card industry; status services can be useful when trying to address privacy concerns and reputations as well as managing authorization for installation or execution of software - you tend to label these types of applications as "low value" or "no value."
in addition to ocsp ... about the same time there were some other
infrastructures looking at various gimicks to improve the revokation
process. note in the following announcement ... they were almost
quoting me word-for-word about how archaic the CRL process actually
is.
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.
I think it's worth noting that for a particular application one could, in a competitive market with multiple providers, compare the policy of various SPs to compare their ability and willingness to offer higher sensitivity status services (small cache time to live) as in indication of exposure when relying on their services just as one could compare authentication policy to the same end. Consider further that some CAs could not qualify their public services under various US government regulations, and indeed are not approved to issue certificates under those regulations in various US states, nor meet the recommendations of various expert groups including ISO and the ABA ISC but instead tend to cite minimal WebTrust accreditation which is primarily targetted at having CAs reveal their practices and not so much specify what those practices should be (which WebTrust provides guidenace through examples but does not require for their 'certiffcation').
At the heart of these matters is an evaluation of proper policy, this is theoretically the discussion of the maligned private discussions between some of the browser / OS / and CA service providers out there. In theory that group will go public with a set of recommendations that are compatible with the existing US regulations and various specification group recommendations that many in the public CA space do not meet under their current practices. Presumably at that time the browser providers will have to scrub their root lists to eliminate the weaker players or maybe the weaker players will overhaul their practices to comply with existing regulation and practice.
It is unfortunate that as a society we know how to value financial transactions and defend against them but the mechanisms for individual privacy protection are not as well represented. One can the credit card industry evolving lock step with fraud as they release new mechanisms for protecting themselves (mostly protecting the banks than the merchants who essentially buy insurance from the various bank and financial network operators). One can see in other environments where this happens; consider the the wireless network bandwidth owners continue to take measures to protect their resources by increasing the tools they have for managing what content is executed on their platforms which could be stealing bandwidth by using network resources without the users approval (generally this is done by using CA services).
Given that individiaul privacy doesn't have a directly measurable value to a business there is not the same motivation to protect it and so most individuals rely on the various community participants to do the right thing which, given the long feedback loop, is taking longer than many of us would want.
cordially,
ram
