Financial Cryptography: Comment on The One True Identity -- cracks being examined, filled, and rotted out from the inside

Comments: The One True Identity -- cracks being examined, filled, and rotted out from the inside

so can some of this be merged into a comprehensive paradigm for the public ... which also has some spill over from a number of other recent threads

so in this (and other) thread:
http://www.garlic.com/~lynn/aadsm26.htm#44 Governance of anonymous financial services
http://www.garlic.com/~lynn/aadsm26.htm#48 Governance of anonymous financial services
http://www.garlic.com/~lynn/aadsm26.htm#49 Governance of anonymous financial services

i claimed that the work on x9.59 financial standard protocol in the mid-90s ... attempted to take into account some sort of EU directive about financial transactions at point-of-sale should be as anonymous as cash.

the x9a10 financial standard working group, in the mid-90s had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments ... resulting in x9.59
http://www.garlic.com/~lynn/x959.html#x959

we claimed that x9.59 was privacy agnostic ... the only thing exposed at retail point-of-sale was an account number. It was then up to various jurisdictions whether there was any association/binding for the account number. In many jurisdications there are "know you customer" requirements that at some point requires a binding between an account number and an individual ... at least for credit & debit transactions. "stored-value" account numbers are still allowed to be anonomous in many jurisdications ... all of these can be supported by a common x9.59 protocol.

for even more drift
http://www.garlic.com/~lynn/aadsm26.htm#47 SSL MITM-attacks makes the news
http://www.garlic.com/~lynn/aadsm26.htm#50 DNSSEC to be strangled at birth
http://www.garlic.com/~lynn/2007q.html#58 Can SSL sessions be compromised
http://www.garlic.com/~lynn/2007q.html#60 Can SSL sessions be compromized

part of the issue is that how an entity is referred to (identification) and and what trust, privileges and permissions might be granted that entity are totally different operations. It may be possible to have a single, unique method of referring to an entity ... but that would never carry with it the sense of trust/privileges/permissions which are nominaly extremely context sensitive. This has been one of the places that "digital certificates" have frequently strayed into dangerous waters ... attempting to bolix up identification, authentication, trust, privileges, and permissions into one big mash.

so for slightly more drift, a scenario is to take address books, bookmarks, pgp key management, certificate management, etc ... and merge them all into a single (context specific) contact metaphor

rather than having to educate the public about what pgp keys are and certificates are ... they become a trust attribute related to contact. the downside is this somewhat commoditizes the whole PKI/certificate paradigm for the public. It is no longer a unique high-priced operation, it is significantly simplified as a contact attribute/characteristic (The CA is a "contact" and it can be trusted to provide some kinds of trusted information about other contacts).

(email) pgp key lookup and (URL) public key lookup at domain name system can appear as a single operation ... checking/validating the trust of a contact ... just another characteristic/attribute of contact.

the simplification is to take a single metaphor that the public is already used to dealing with and merging all the myriad of disparate operations into that single metaphor.

the claim can be made that trust hierarchy metaphors don't go over well with the public because it doesn't match how most of the public deal with the world.

however, it is fairly well established that the public can deal with the world within a contact metaphor ... where trust could then become an attribute within the contact metaphor (however, this may drastically minimize the heights that some institutions try to raise the status of trust to an extremely expensive independent paradigm).

the issue here is that the current SSL deployment fails to account for the large gap that exists in the publics' mind between webservers they think they are talking to and the URL that is used to contact those webservers (and SSL only provides a check on whether the webserver being talked to and the URL used to talk to the webserver are consistent).

contacts can provide a methaphor for the public ... that spans the gap. then there are two symbols that might be displayed for a URL ... one is its "trust" level symbol (from the contact repository) and the other is the padlock ... which is purely related to whether the transmission is being encrypted over the internet (i.e. the trust of the site and whether there is countermeasure for evesdropping are two independent characteristics).

Using consistent paradigm for all kinds of contacts ... then could also mean that there be a consistent metaphor/representation for trust and encryption across URLs, email, instant messages, etc.

contacts might include globally unique identifier ... but also have local, context specific trust, permissions, privileges, etc.

Posted by Lynn Wheeler at April 8, 2007 05:47 AM

Lynn,

possibly, the notion of using a contact metaphor has been explored with the Bookmarks metaphor. The Petname concept has found some ease of implementation by merging with the Bookmarks in web browsers. And while Petnames are hard to describe, Bookmarks are easy.

When a user adds a bookmark, she names it how she wants. This becomes a petname to a resource, a local, user-defined-and-known private name. By adding a little crypto trickery (hash of the public key of the server) to the bookmarks database, then we create a secure petname and this can be used by a plugin to positively identify a repeat visit.

The concept works and works well (Petname Toolbar is a minimalist design, Trustbar also develops it further, and later generation toolbars have incorporated the idea). It requires a slight user training. One can criticise this on the basis that users don't do anything, and can't be trained at all; or one can say this is the best bang for buck that is currently available, for those who can be trained, if we assume that user information has to be tapped in some sense as a better or useful relationship.

Posted by Iang at April 8, 2007 06:58 AM

re:
http://www.garlic.com/~lynn/aadsm26.htm#51

contacts (with address books) have frequently added several additional optional information. making single consistent implementation for all activity might simplify the web experience ... driving all from a single interface/metaphor.

some address books already have automatic adding email addresses ... but without additional information ... however the additional fields are there. so an equivalent might do something equivalent for URLs ... possibly starting only with ones that claim HTTPS. then additional fields might be optionally selected.

in some ways this might be viewed as analogous operation to IE domains ... but instead of being driven off the (security) domain metaphor (and specifying URLs for each domain) ... it is driven off a (single) contact metaphor ... selecting what optional information gets specified for a URL.

optional information could be policy collections ... analogous to IE domains ... and/or specific permissions.

the difference is that it changes from a security metaphor to a (single, consistent) contact metaphor.

Getting a bank's URL loaded into contacts list with various online banking related attributes ... then can start to close the existing (SSL) gap between the server that a user thinks they are talking to and the URL.

This would make web-based banking operate somewhat more like the financial packages (quicken, money, etc) ... where registration of the financial institution for banking is required (even tho under the covers the financial packages may be using SSL for encryption).

Also more analogous to operation of earlier online banking operations that had installed software with the necessary contact information for doing direct dialed operation.

In the mid-90s, there were a couple of financial institution presentations that mentioned that existing online banking software required the financial institution to directly support something like 50-60 different flavors of modem drivers (different modem products, different operating systems, etc) as well as have call-center support for dailin operation.

Transition of online banking (or other online operations) to "Internet" was enormous savings for the institution since it effectively outsourced all the online gorp to an external organization ... and the external organization was able to amortize the online connectivity across a broad range of (additional) offerings/services to the consumer.

This consolidating of a large number of offerings/services was an enormous cost savings to individual institutions and enormous benefit to the consumer ... but also created a large ambiquity about who the consumer was dealing with at any specific point in time (and SSL doesn't actually provide complete end-to-end coverage eliminating all of that ambiquity).

The consumer direct registering of attributes for specific contact ... would somewhat close the gap (left by SSL). It also removes some of the disintermediation(?) that was introduced by the internet and 3rd party CAs between the consumer and the institutions that they were dealing with (compared to earlier "direct" online software packages)

The problem is that could also be viewed as eliminating the excuse for 3rd party CAs charging institutions for digital certificates ... since all that could be subsumed by user specifically loading institution contact information (and SSL changed to directly use loaded public key in the contact information).

Posted by Lynn Wheeler at April 8, 2007 12:10 PM

re:
http://www.garlic.com/~lynn/aadsm26.htm#51
http://www.garlic.com/~lynn/aadsm26.htm#52

to even further extend the topic drift ... in the 90s, i gave a couple conference talks as well as a graduate student seminar at ISI (USC) that included the IETF editors organization.

It basically was that there had been a lot of protocols migrated from circuit-based infrastructure to Internet (packet) operation ... w/o taking into account that there were a lot of implicit characteristics of the end-to-end circuit operation that were lost in the transition to packet operation.

When we were called in to consult with a small client/server startup about doing payment transactions on their server (with some technology they had called SSL ... and since has frequently come to be called electronic commerse), we had "sign-off" on the server to payment gateway implementation (I somewhat facetiously joke is the original SOA implementation).
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

One of the things we specified was extensive "compensating procedures" (and added business critical dataprocessing features) as part of moving financial transaction operation from circuit-based operation to packet-based operation. We also tried to suggest that some similar stuff should be implemented in the browser to server interface ... however we would get back responses like "that is too complicated" ... and since we only had sign-off on the server/gateway implementation we couldn't force it.

some recent posts mentioning the topic:
http://www.garlic.com/~lynn/2007.html#15 SSL info
http://www.garlic.com/~lynn/2007.html#28 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007f.html#37 Is computer history taught now?
http://www.garlic.com/~lynn/2007g.html#38 Can SSL sessions be compromised?
http://www.garlic.com/~lynn/2007g.html#51 IBM to the PCM market

for other drift ... at the time I was doing some work with the RFC editor related to RFC index and consistency of information in STD1. That RFC index work continues and is at
http://www.garlic.com/~lynn/rfcietff.htm

Posted by Lynn Wheeler at April 8, 2007 01:39 PM