there are several other disconnects between ssl domain name certificates and the infrastructure .... and the primary use of ssl and e-commerce
http://www.garlic.com/~lynn/subpubkey.html#sslcert

1) one of the things that ssl domain name certificates were countermeasure to ip-address hijacking ... namely that the URL that the user entered got them to the correct web site ... and the website they thought they were talking to, was in fact, the website they were talking to.

the chain of trust then had certification authorities, certifying that the certified public key actually belonged to the owner of the specific domain name (that would be used in the url).

the first disconnect came when e-commerce sites figured out that using SSL consumed 80-90 percent of their capacity and started relegating SSL to purely check-out/purchase phase. The user now clicks on a button (from the website) that automatically supplies a URL ... which is then verified by a certificate (also supplied by the website). This creates a break in the chain of trust, since the URL originally provided by the user is no longer being verified.

the next disconnect came with the wide-spread adoption of users purely clicking on all sorts of buttons and field ... hardly ever acutally manually entering a URL themselves. this has shown up in various kinds of phishing and spam attacks where users are requested to click on an email field that purports to represent some URL ... but in fact, may take the user to a fraudulent website (which can include man-in-the-middle attacks).

part of the financial disconnect has been that e-commerce has been extremely skewed. the large sites are extremely well known as is their URL(s) and they do the majority of the transaction. its is the millions of merchants that only do a few transactions where there is the greatest risk (but they can't justify a costly extraneous expense).

the merchants are also already paying premium to insure consumer credit card transactions. the issue for SSL domain name certificates is what additional benefit would they provide to anybody, that would justify paying a lot more money (other than well publicised compaign where consumers feel greater comfort when SSL is used, aka the merchant comfort certificates). To some extent certificate authorities are competing with credit card interchange fees that is already covering fraud exposure to consumers (bad things happening).

2) another issue with the ssl doman name certificates, is that the certification authorities have to resort to verifying the domain name owner with the authoritative agency for domain name ownership, which turns out to be the domain name infrastructure ... the agency that also has various possible integrity issues ... like ip-address hijacking, which is one of the original justifications for having ssl domain name certificates.

another integrity issue with domain name infrastructure is domain name hijacking vulnerabilities. having various vulnerabilities with the authoritative agencies responsible for the information that certification authorities are certifying ... can result in the certification authorities performing one hundred percent and still certifying erroneuous information.

so, somewhat with the backing of the certification authority agency, there is proposal that all domain name owners register a public key as part of their domain name registration. this can close some number of vulnerabilities for domain name infrastructure (like ip-address and domain name hijacking), improving the integrity of the domain name
infrastructure.

the certification authorities currently have an expensive, time-consuming and error prone process where they require a SSL domain name application to provide a lot of identification which they then have to try and match with the identification information on file (for the domain name owner) with the domain name infrastructure. going to onfile public keys, the certification authorities can require that SSL domain name certificate applications be digitally sign. Then the certification authority can do a real-time retrieval of the onfile public key to verify the digital signature (replacing an expensive, time-consuming and error prone identification process with a much simpler, less expensive, and reliable authentication process).

the problem is that the onfile public keys represent a catch22 for the certification authorities. improving the integrity of the domain name infrastructure, decreases the original justification for having ssl domain name certificates. also allowing anybody to do real-time
retrieval of onfile public keys means that general public could authenticate websites directly without requiring digital certificates at all.
http://www.garlic.com/~lynn/subpubkey.html#catch22

3) business model that is out of synch with traditional business processes. normaly a relying party has a contract with an authoritative party where they pay directly for the services they receive (exchange of value). in the standard 3rd party certification authority business operation, the certification authority sells a certificate to an key-owner/end-user (and *NOT* the relying party). The relying party then has absolutely no relationship contractual, implied, or any other way) with the certification authority and/or any duties related to the certification authorities duties.

The Federal PKI project somewhat dealt with this aspect by having the GSA (acting on behalf of the federal gov. agencies that would be relying parties) sign a contract with all "authorized" certification authorities (creating a contractual obligation between the relying parties and the certification authorities).

in the ssl domain name certificate infrastructure scenario, this would imply having every possible consumer/client (hundreds of millions or even billions) sign a contract with every possible certification authority (at least tens). the business plan of selling ssl domain name certificates to a few million merchant sites would be totally swamped by the costs of having to deal with tens of billions of individual consumer contracts (with the consumer as a relying party).

4) advent of ubiquitous online connectivity. the primary design point for digital certificates were in offline environments, analogous to letters of credit/introduction from sailing ship (and earlier days) ... where the relying party lacked any ability to directly access the responsible or authoritative agency. digital certificates designed for offline operation can become quickly obsoleted when the relying parties have direct, real-time access to the responsible authoritative agencies (like possibly being able to do real-time retrieval of onfile public keys from the domain name infrastructure)

this has somewhat pushed digital certificates into the low/no value market segment where relying parties can't justify the expense of real-time operation for whatever business operation they are involved in. however, with the rapidly declining costs of data processing and online access, the places where relying parties can't justify real-time, online operation is also shrinking/declining. it is quickly becoming an extremely small no-value operation that can't justify real-time, online access.

lots of past posts about certification authorities being manuvered into low/no value market segment (and if you are dealing with no-value operations, its hard to justify charging a lot)
http://www.garlic.com/~lynn/aadsm11.htm#42 ALARMED ... Only Mostly Dead ... RIP PKI ... part III
http://www.garlic.com/~lynn/aadsm12.htm#26 I-D ACTION:draft-ietf-pkix-usergroup-01.txt
http://www.garlic.com/~lynn/aadsm12.htm#27 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#52 First Data Unit Says It's Untangling Authentication
http://www.garlic.com/~lynn/aadsm12.htm#55 TTPs & AADS (part II)
http://www.garlic.com/~lynn/aadsm13.htm#4 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#5 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#14 A challenge (addenda)
http://www.garlic.com/~lynn/aadsm16.htm#22 Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
http://www.garlic.com/~lynn/aadsm17.htm#9 Setting X.509 Policy Data in IE, IIS, Outlook
http://www.garlic.com/~lynn/aadsm17.htm#53 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm19.htm#8 GeoTrust says existing PKI practices are worthless
http://www.garlic.com/~lynn/aadsm20.htm#33 How many wrongs do you need to make a right?
http://www.garlic.com/~lynn/aadsm20.htm#42 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm20.htm#44 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm21.htm#20 Some thoughts on high-assurance certificates
http://www.garlic.com/~lynn/aadsm21.htm#36 browser vendors and CAs agreeing on high-assurance certificates
http://www.garlic.com/~lynn/aadsm23.htm#1 RSA Adaptive Authentication
http://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security' site.
http://www.garlic.com/~lynn/2002m.html#30 Root certificate definition
http://www.garlic.com/~lynn/2002n.html#42 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002o.html#56 Certificate Authority: Industry vs. Government
http://www.garlic.com/~lynn/2002o.html#57 Certificate Authority: Industry vs. Government
http://www.garlic.com/~lynn/2002p.html#22 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2003b.html#50 Authentication w/o user ids and passwords
http://www.garlic.com/~lynn/2003l.html#33 RSA vs AES
http://www.garlic.com/~lynn/2003l.html#45 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2004b.html#25 Who is the most likely to use PK?
http://www.garlic.com/~lynn/2004b.html#52 The SOB that helped IT jobs move to India is dead!
http://www.garlic.com/~lynn/2004e.html#20 Soft signatures
http://www.garlic.com/~lynn/2004h.html#52 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#2 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#2 Authenticated Public Key Exchange without Digital Certificates?
http://www.garlic.com/~lynn/2004j.html#15 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2005e.html#62 TLS-certificates and interoperability-issues sendmail/Exchange/postfix
http://www.garlic.com/~lynn/2005g.html#34 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005i.html#13 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005i.html#24 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005k.html#29 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005k.html#60 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#1 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#11 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#21 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#23 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#25 PKI Crypto and VSAM RLS
http://www.garlic.com/~lynn/2005l.html#29 Importing CA certificate to smartcard
http://www.garlic.com/~lynn/2005l.html#33 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005l.html#37 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005o.html#40 Certificate Authority of a secured P2P network
http://www.garlic.com/~lynn/2005s.html#49 phishing web sites using self-signed certs
http://www.garlic.com/~lynn/2005t.html#0 TTP and KCM
http://www.garlic.com/~lynn/2006c.html#16 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#39 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#29 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#31 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#35 X.509 and ssh
http://www.garlic.com/~lynn/2006h.html#28 confidence in CA
http://www.garlic.com/~lynn/2006i.html#13 Multi-layered PKI implementation

The role of the mandatory insurer is more pernicious, than at first blush one might perceive. The insurer becomes guard, overseer, policy puller and general nazi - acting in the name of public policy. Do as we say, in "notifying" of us of any material breach of the security policies that we impose, and then be constancy subject to arbitrary decisions of whether we pull our insurance. Of course, if we pull the coverage, your financial responsiblity assurance is blown, and we put you out of (licensed) business, thereby.

The most pernicious of the previous attempts to enforce govt policies on mandatory key escrow by the back door, by means of this financial responsibility assurance rule (requiring insurance-based security policy enforcement and control, generally), was in Australia, in about 2001, headed up by folks associated with PWC. It only failed because the US government side was not willing to be seen to be pulling the same strings, on the US end - despite having agreed with the coordinated initiative, behind closed doors.

PKI has always been tying scheme (a smart contract that forces you to buy additional services to get crypto) sold as a security scheme.

A good read and I'd like to highlight and comment a few remarks from that blog:

Microsoft voted "yes" but this is a game they can play, they are better than anyone else at it, and they also have a motive: the Cardspace (was infocard) project needs friends and EV is a friend looking for friends, also.

OpenID is doomed to fail as well, if they continue the current path...and the irony of it is, that it will suffer from the same threats (phishing, spaming, identity theft) but for the opposite reasons (i.e. no governing control, no requirements, lax standard). But this is now off-topic...

Likely the EV project will fail, due to the simple mathematics of it. Too few target sites (<<1000) and too much cost in audits, re-checks...

Not, if it can be acquired by the general public, which implies, that the costs for the CAs must be much lower, or as you phrased it, the "barrier to entry" must be reasonable. Obviously the infrastructure for "extended validation" already exists with most CAs...it's the subscribers voting with their purse why common web sites don't use them...

Instead, we get the same old PKI hobby horses: must run a good OCSP...

For example like this? http://www.startcom.org/img/verisign-ocsp.png compared to http://www.startcom.org/img/startssl-ocsp.png :-D (Screen shots from the 9th of February 2007). BTW, Opera doesn't know what to do with CRLs....we are certainly living in interesting times...

Browsers also should say "no." Or, should say, "sure, as long as it is an open market in governance." There is this underlying premise that the cartel known as the CA/Browser forum is //the only one. No such. There is no reason why I can't form a cartel made of, say, European national CAs or open source software CAs or Internet Bank CAs or ... and simply request the colors purple, peach and turquoise.

Absolutely! Any new standard which comes along by any interest group should be accepted by the browsers vendors...sounds reasonable, doesn't it!?