The great coupe is at hand Microslop Bank is hiding in the bushes with so much dam money they only way they can continue to grow is be an internet bank which means be the bank of first and last choice. Advertising is nothing when compared to controlling the systems that process payments and extend credit, Credit is the reason for ID and since CA’s are already regulated the perfection of ID and CA are not far off from Microslop offering credit. Imagine if you will a massive mall where advertising and payments are combined and instant credit offered. Retail music downloads receive 50%, gambling keeps 80% of the money, and credit can if not paid on time charge fees that would knock your eyes out. The interesting feature is online transaction processing does not require a bank charter and the receivables can be securitized immediately and the risk passed on to the capital markets. The timing is perfect the housing boom is over and refinancing has all but dried up so consumer users are easy pickins simply offer credit because no one else will. The Microslop Credit Corp will sell cars, televisions, do auctions, and sell just about everything that can be paid for online with Microslop Credit. http://www.ss.ca.gov/digsig/digsig.htm
Approved Digital Signature Certification Authorities Certification Expires
Digital Signature Trust / an Identrus company
255 North Admiral Byrd Road
Salt Lake City, Utah 84116-3703
Phone: 801-326-5400
Fax: 801-326-5448
www.trustdst.com November 18, 2005
Entrust, Inc.
One Hanover Park
16633 Dallas Parkway
Suite 800
Addision, Texas 75001
Phone: 613-270-3157
Fax: 613-270-2503
www.entrust.net (Certificate Information)
www.entrust.com August 25, 2006
Verisign, Inc.
487 East Middlefield Road
Mountain View, California 94043
Phone: 650-961-7500
Fax: 650-961-7300
www.verisign.com October 3, 2006
GeoTrust, Inc.
117 Kendrick Street, Suite 350
Needham, MA 02494
Phone: 781-292-4126
Fax: 781-444-3961
www.geotrust.com July 28, 2006

when we were doing the original payment gateway as part of the commerce server doing payment transactions
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

looked at some number of additional things that a certificate could represent, in addition to straight-forward ssl domain name certification.

recent post about ssl domain name certificates being compromised because original design had the user typing in the url and then the server supplied certificate matched the typed in URL implied that the server the user thot they were talking to was the server they were talking to (implicit was belief that the end-user had understanding between some entity and the URL)
http://www.garlic.com/~lynn/2006d.html#28

as the environment evolved to users simply clicking on buttons or other things (potentially supplied by an attacker) ... the ssl domain name certificate just came to mean that any attacker was who they claimed to be

our proposals about including more detailed checks on e-commerce merchants possibly including things like fbi background checks on all proposals didn't catch on (also mentioned in the above post).

part of the issue was financial justification for doing the additional checking. a merchant/acquiring financial institution already does a fairly detailed check on any credit card accepting merchant (since part of a merchant/acquiring financial institution sponsoring a merchant for accepting credit card transactions ... includes taking financial liability for the merchant).

there was an issue with whether an end-user could trust an unknown merchant. the e-commerce activity was highly skewed with the majority of transactions occuring with well known and well branded websites, frequently repeat business. A small percentage of total e-commerce activity was spread across the large number of websites ... each website only performing a few transactions each. The high volume merchants didn't need anymore trust ... since they had the brand and repeat business. The low volume merchants couldn't justify paying more for trusted certification ... other than what they were already paying to their merchant/acquiring financial institution.

this was still in the days when it was assumed that the user was typing in the URL and was familiar with the entity associated with the URL.

the evoluation came with the disconnect with what the users perceived to be entities and clicking on arbitrary strings that provided the URL to the browsers. This created a disconnect between what the user perceived to be the entity and the URL supplied to the browser. Attackers could provide things to click on that claimed to be some well-known entity, but actually generated some totally unrelated URL. Then the attacker only had to provide a certificate that proved that they were who the URL claimed they were (as opposed to textual claims as to who they were).

So there a possible a couple different countermeasures to vulnerability/exploit. One is to create some variety of trusted "clicks" (which have evolved as a substitute for actually typing in the URL). As part of creating trusted "clicks" there is some user involvement in establishing the relationship between who the user thinks the entity represented actually is, the "trusted" click, and the resulting URL (which was implicit in the original SSL model that assumed the user would be typing in the URL value and understood the relationship between some entity and their URL).

An alternative is some sort of high assurance certificate and some browser visual indication when the browser is dealing with a high assurance certificate (as opposed to any run of the mill certificate).

The high assurance certificates doesn't eliminate the disconnect for end-users where some text can claim that clicking will invoke one thing ... but actually invokes something else different (the only thing that ssl domain name certificates does is prove that you are who your URL claims you to be ... as opposed to what any surrounding text may claim you to be).

Implicit is an assumption that attackers won't be able to obtain a high assurance certificates (and all the entities that can obtain high assurance certificates won't involve themselves in impersonations).

to some extent the certificate-base model is that the end-user needs to have no local support infrastructure ... that it can all be supplied by institutional entities.

the "trusted" click model assumes that the end-user has some sort of local support infrastructure ... for recording and preserving their "trusted" clicks. "trusted" click model could even allow clicking on externally supplied clicks ... and having the browser tell you whether it mapped to a trusted click entry and who was the entity associated with the entry (even visual clues similar to that proposed for high assurance certificates).

I can imagine only two workable models of certification:
1. one that comes together with the domain registration, issued by the registry.
2. Title insurance, like for real estate in California (and possibly elsewhere). The insurer (the CA, in this case) will compensate anyone defrauded using the fact that the title (the identity, in this case) did not, in fact, belong to the insured party.

from the end-user standpoint, the "trusted click" paradigm, using something analogous to bookmarks, can be quite similar to cellphone phone books (using caller-id to maps to different ring tones) or email address books (where spam blockers may rate incoming different if the origin address is in the address book).

that doesn't address spoofing the origin email address or spoofing the caller-id ... but in the web paradigm, basic ssl is used to catch that type of spoofing.

the current issue is the disconnect with the click paradigm ... where users are presented with to something to click ... and attempts are made to obfuscate the URL domain name (SSL provides the connection between the URL domain name and the website ... but the click paradigm allows for a disconnect between the end-user and the actual URL domain name coming off the click).

digital certificate cps, gov. legislation, and audits can be viewed as attempts to get around the TTP/CA business model being alien to standard business operations. In standard business operations, the relying party has business relationship with the certifying agency and typically there is some exchange of value (implicity or explicity contract). In the typical TTP/CA business model there is no business relationship and/or obligation between the CA and the relying parties. CPS, gov. legislation and audits are approaches that attempt to provide a sense of comfort for relying parties in certifications performed by CAs (where it doesn't otherwise exist in normal business practice).

GSA addressed this in the Federal PKI by signing contracts with all approved certifying agencies issuing digital certificates .... essentially making them agents of GSA (for issuing digital certificates). Then federal gov., as relying party, could rely on the issued digital certificates because of their (gsa) contract with the certification authorities.

note in previous comments, theoritical use of digital certificates is by relying parties where they have no information about the subject entity and/or no way of obtaining such information. in the digital certificate analogy to letters of credit/introduction, the relying party
(when there was no other means of obtaining information) could record information from the letters of credit/introduction in their local repository. typically a letter of credit/introduction wouldn't be repeatedly presented on every interaction, but recorded locally. the local record is then used for future interactions.

so a local trusted repository (bookmarks, public key repository, address book, phone book, etc) is used to record information about interactions. when no other information is readily available (either locally or via direct contacts with reputable agencies ... in the domain name case, it could be direct contract with the domain name infrastructure and retrieving registered public key at the same time registered ip-address is retrieved), then individual's local repository might be populated on first-time interaction between two total strangers with information supplied by digital certificate.

Paradigm that repeatedly presents such credentials on every interaction typically assume that the relying party has no ability to maintain local repository.

The scenario of acquiring/merchant financial institutions implicity certifying merchants that can perform credit card transactions, involves contracts between consumer and their consumer/issuing financial institution, the consumer/issuing financial institution and the associations, the associations and the acquiring/merchant financial institution, as well as the acquiring/merchant financial institution and the merchant. this series of contracts creates obligations between the consumer and the merchant. furthermore, the acquiring/merchant financial institution stands behind the merchant (taking financial liability), and in return takes a percentage of every financial transaction.

In the title insurance scenario ... the relying party (consumer) pays the title insurance company for the certification (direct business contract between the relying party and the certification agency).

As mentioned, in the typical TTP/CA business operation there is no direct contractual relationship between the relying party and the certification agency.

slight drift, part of thread on caller id "spoofing"
http://www.garlic.com/~lynn/2006d.html#31

which is the analogy between the URL and the webserver and is directly addressed by ssl domain name certificates ... which is different than the vulnerability created with the browser "click" disconnect. lots of past posts about ssl domain name certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert

for even more drift, a recent posting about frequent semantic confusion the result of having the word "signature" occur in both the terms "human signature" and "digital signature"
http://www.garlic.com/~lynn/2006d.html#34 When *not* to sign an e-mail message?