Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes: > also, i remember OCSP coming on the scene sometime after I had been > going for awhile about how CRLs were 1960s technology (and least in > the payment card business) .... before payment card moved into the > modern online world with online authentication & authorization > (moving away from having to manage credentials/certificates that had > been designed for an offline paradigm).
for instance in an offline credential scenario ... you would place the person's date of birth in the credential several years ago, we did a survey of corporate databases for security issues ... one was a field by field analysis of types of information and the vulnerability. for instance ... any information where we could find a business process that made use of that information for authentication ... was labeled as having an "id theft" vulnerability. several business processes made use of knowledge about date-of-birth for authentication purposes ... and therefore date-of-birth was given an id-theft attribute (we made claims at the time about being able to do semantic semantic analysis rather than purely syntactic security analysis). these kinds of information was the types of things being looked at in the early 90s to grossly overload x.509 identity certificates ... in the anticipation that some random relying-parties in the future (after the certificate was issued) might find the information to be of some use. it was issues like these that prompted some institutions in the mid-90s to retrench to relying-party-only certificates ... effectively containing only a pointer to the real information in some accesable database. however, these databases were typically part of an overall relationship management and administrative function ... which made the function of stale, static certificate redundant and superfluous. Now in the late 90s, tstc http://www.fstc.org/ was looking at fast protocol which would respond to certain kinds of questions with yes/no. they would utialize existing 8583 interconnect network structure ... but extend 8583 transactions to include non-payment questions ... like whether is the person an adult or not. The real-world, online authoritative agency could simple respond yes/no to the adult question w/o divulging a birth date ... which represents an identity theft vulnerability. part of the issue prompting the fast protocol was the appearance of a number of online services selling transactions on whether a person was an adult or not. this online services were having people register and supply credit card information for doing a "$1 auth" transaction that would never clear. Their claim was that since people that had credit cards had to sign a legal contract, and to sign a legal contract, you had to be an adult ... then anybody that performed a valid credit card transaction must be a valid adult. As a psuedo credit card merchant they paid maybe 25cents to perform the "$1 auth" to get back a valid authorization response. Since they never cleared the transaction ...it never actually showed up as a transaction on the statement (although there was a $1 reduction in the subjects open-to-buy for a period). An issue was that the adult verification services were making quite a bit of money off of being able to perform a transactions that brought in only 25cents to the financial institution ... and the whole thing involved, online, real-time responses ... no stale, static, redundant and superfluous certificates designed to address real-world offline paradigm issues (and which also tended to unecessarily expose privacy and even identity theft related information). -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ _______________________________________________ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
