Ram A Moskovitz <[EMAIL PROTECTED]> writes: > 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.
one of the reasons given for the migration away from x.500 and x.509 identity certificates in the mid-90s, where the enormous privacy and liability issues that they represented (if they contained enormous amounts of openly available) personal information). referenced in previous new postings http://www.garlic.com/~lynn/2500l.html#34 More Phishing scams, still no SSL being used however, it is trivial to show that if the relying-party is going to access some form of relationship management infrastructure containing all the real information, then any stale, static digital certificates are redundant and superfluous. the issue of PKIs moving into no-value transactions .... is that a relationship management infrastructure typically contains a lot more timely and higher quality information for making decisions. If the infrastructure can justify the value of having higher quality online information ... then the PKIs and stale, static digital certificates are redundant and superfluous. That leaves PKIs looking for the rapidly shrinking markets where 1) the relying party can't access the real information directly (restricted to offline environment) and/or 2) the relying party can't justify the need to have direct and timely, higher quality information. in the mid-90s, FSTC http://www.fstc.org/ was in a quandary over FAST ... basically doing simple digitally signed transactions but expanding them to issue more than financial transactions. there are some implied reference to that opportunity in the old news posting http://www.garlic.com/~lynn/2500l.html#34 More Phishing scams, still no SSL being used in the x9a10 financial standard working group, we were charged with preserving the integrity of the financial infrastructure for all retail payments. the x9.59 standard was the result http://www.garlic.com/~lynn/index.html#x959 it basically is the minimum payload increase to existing payment messages. it can be mapped to iso 8583 debit, credit, and stored-value messages http://www.garlic.com/~lynn/8583flow.html with the addition of a couple additional minimal fields and a digital signature (and no enormous payload bloat by appending stale, static, redundant and superfluous digital certificates). The FAST scenario was basically to enable the asking of yes/no questions about things other than financial transactions (i.e. the title of the referenced news article: *Privacy Broker: Likely Internet Role for Banks?*). For instance a merchant could ask if the person was of legal drinking age. There was no requirement to divulge the actual birthdate (birthdates are widely used as a means of authentication, so divulging birthdates represents an identity fraud thread). The FSTC/FAST scenario was that there is a large and thriving internet business for age verification .... but it involved a segment of the internet business that many consider unsavory. However, the widespread deployed implementation was based on an intermediary doing a "$1 auth" credit card transaction as part of registration. The "$1 auth" would never be settled, so there was never any actual credit card charge (although your credit limit or "open to buy" would be decremented by a dollar for a couple days until the auth had expired). The theory was that a person had to be of legal age to sign a credit card contract, which in turn enabled them to do credit card transactions. There was a lot of money being made off of this "$1 auth" hack ... and only a very small amount going to the financial industry. Note however, FAST was never intended to only be limited to age verification ... but age verification was viewed as an already well-established market. When we were called in to work on the cal. state and federal electronic signature legislation, one of the industry groups had done studies on the driving factors behind privacy regulation and legislation. The two main driving factors were 1) identity theft and 2) (institutional) denial of server; aka the primary driving factors weren't privacy itself ... it was the prospect of fraud and/or being denied a job or various kinds types of services. so as implied in the previous post http://www.garlic.com/~lynn/2005l.html#35 and the post on security proportional to risk http://www.garlic.com/~lynn/2001h.html#63 many relationship management infrastructures have strongly conflicting business confidentiality objectives ... readily available for use by lots of business processes and at the time not being available hardly at all because there is authentication information that can also be used to impersonate and originate fraudulent transactions. harvesting of such repositories is frequently made easier because of the large number of different business processes that require access to the information (in some cases the transaction information even defines the authentication information). going back to the secruity PAIN acronym P ... privacy (or somethings CAIN, confidential) A ... authentication I ... integrity N ... non-repudiation the businesses tend to have a strong *integrity* frequiement for their relationship management systems (various kinds of integrity issues like introduction of incorrect values can affect their bottom line). However, they tend to have a more lower *privacy* requirement for their relationship management systems (in part because a large number of different business processes require access). When an insider swipes the information, they tend to go far away to do their account/identity fraud. I'm also a co-author of the x9.99 financial industry privacy impact assessment (PIA) standard. Most companies understand using security (and frequently integrity) to protect themselves. However, it frequently takes a change in mindset to start using security (and frequently privacy) in the protection of others. minor note ... as part of x9.99, i also started a privacy taxonomy and glossary (trying to help organize how you think about privacy): http://www.garlic.com/~lynn/index.html#glosnote One of the issues with the posting on security proportional to risk ... is that even if you blanketed the earth under miles of cryptography, the current infrastructure still can leak information that can be used in account and identity fraud. One of the things in the x9.59 standard http://www.garlic.com/~lynn/index.html#x959 was that it removed knowledge of an account number as point of compromise. Given that the account number is used in an enormous number of business processes ... trying to keep it confidential appears to be an impossible task. so x9.59 changed the rules, it made the account number useless to crooks for performing fraudulent transactions: 1) x9.59 transactions had to be strongly authentication 2) account numbers used in x9.59 transactions could not be used in non-authenticated transactions aka gave up on trying to keep the account number confidential ... just made knowledge of the account number useless to crooks for account/identity fraud. misc. related postings http://www.garlic.com/~lynn/aadsm6.htm#terror7 [FYI] Did Encryption Empower These Terrorists? http://www.garlic.com/~lynn/aadsm6.htm#terror13 [FYI] Did Encryption Empower These Terrorists? http://www.garlic.com/~lynn/aadsm8.htm#3dvulner 3D Secure Vulnerabilities? http://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI) http://www.garlic.com/~lynn/aepay11.htm#66 Confusing Authentication and Identiification? http://www.garlic.com/~lynn/aadsm14.htm#4 Who's afraid of Mallory Wolf? http://www.garlic.com/~lynn/aadsm15.htm#27 SSL, client certs, and MITM (was WYTM?) http://www.garlic.com/~lynn/aadsm16.htm#20 Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before http://www.garlic.com/~lynn/aadsm17.htm#41 Yahoo releases internet standard draft for using DNS as public key server http://www.garlic.com/~lynn/aadsm18.htm#29 EMV cards as identity cards http://www.garlic.com/~lynn/aadsm19.htm#39 massive data theft at MasterCard processor http://www.garlic.com/~lynn/aadsm19.htm#40 massive data theft at MasterCard processor http://www.garlic.com/~lynn/2000g.html#41 Egghead cracked, MS IIS again http://www.garlic.com/~lynn/2001f.html#24 Question about credit card number http://www.garlic.com/~lynn/2002j.html#14 Symmetric-Key Credit Card Protocol on Web Site http://www.garlic.com/~lynn/2002n.html#14 So how does it work... (public/private key) http://www.garlic.com/~lynn/2003k.html#66 Digital signature and Digital Certificate http://www.garlic.com/~lynn/2004b.html#25 Who is the most likely to use PK? http://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates http://www.garlic.com/~lynn/2004m.html#9 REVIEW: "Biometrics for Network Security", Paul Reid http://www.garlic.com/~lynn/2005k.html#26 More on garbage http://www.garlic.com/~lynn/2005l.html#22 The Worth of Verisign's Brand -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
