Having read through the Extended Validation draft, it is pretty clear that this is "more of the same bad recipe." It didn't work last time, why should we expect the same recipe to work this time? Having said that, there are some interesting aspects.
Firstly, the EV proposal, from a CA group called the CA/Browser forum, asks for, nay, *requires*, that each CA maintain general business insurance, and more specific liability insurance. Further, it goes on to say that each CA must not disclaim liability below $2000.
They are saying, then, it's time to add some meat back into the sandwich of certificates. The "no liability" postures that were discovered about 5 minutes after the CA was invented have often rankled insiders. Wasn't the purpose of the CA to allow the public to rely?
The problem with this was that the CA wasn't in charge, the browsers were, and are. This resulted in the browsers reducing the visibility of the CA to nothing in what was called "the real-estate wars," which meant that the CA was in the worst of positions -- all the liability, none of the glory. The end result is of course all CAs disclaimed all liability; there is no business case otherwise.
Now, redressing that balance is tricky. Forcing the liability to $2000 is like setting the minimum wage to $2000. Are poor people now richer? No, because jobs will be reduced (where the increase doesn't justify) and prices will rise (where the job has to be done). For a perceived benefit of a small group of winners, everyone else pays, and some poor people lose more, which is bad policy and bad economics. Not to mention, it's quite nasty to the poor who lose their low paid jobs and become poorer.
Why doesn't it work that way? Firstly, we simply don't know how to do it. Someone in some council or standards group or wannabe-cartel has "decided" $2000 is a good number. They have no clue what is a good number, they just picked it, perhaps dressing it up with lots of blah blah. Much the same applies to the rest of the "minimum standard" claim, in this particular case, although those standards developed from experience would be excluded from that criticism.
Secondly, they don't have the control to make that number good. Who's in control? The browsers, of course. If the browser doesn't play, the game stops. So what we look for, and what we find, is that the draft is a very carefully designed request for the browsers to hand control over to the forum. Whether they consciously avoided asking the browsers to fix their problems or not, it is clear that there were few demands being made. (Notable exception in the fine print: 37(a)(2) Oops, that could cost you your job, right there.)
In voting for this proposal, word has it that Mozilla abstained, which might mean something or might not. The Register recorded that Verisign let slip and grumbled, soon retracted. Which suggests that this is all being done behind closed doors, and nobody dare say boo in case Mozo or the other browser manufacturers wake up.
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. KDE would probably vote yes, as their openly stated policy is to outsource security policy. Annoying, but you have to admire their honesty. Opera is harder to predict, and Apple are not part of it.
So what happens next? 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, re-issue of keys (yes, required) and so forth and so on.
What then? Even though it looks bad business, we see the herd effect in full play. Many small and medium CAs are being dragged in, for fear of missing out. Perhaps it will be costly to join later? Perhaps they think the market will shift and people will suddenly demand quality? Perhaps they want to play with the big boys?
But cost is the key driver, not hype. It's serious, and given the restrictions, it is likely that only Verisign can pay the price, fully, comfortably. Which means the mid-tier will waste their money. And therein lies the trap. If the mid-tier CAs spend the money, endorse the standard, but cannot make the grade, either by resource depletion or by simply failing to get through all the checks, then who looks good? Verisign, of course. And the mid-tier crumbles.
So this is a dream ticket for the largest player in a competitive market. If it works, they own the EV field as well as extend their brand dominance within non-EV areas. If any mid-tier CAs do manage to get there, that will prove it was worthwhile, as well. If all the rest fail, and Verisign succeeds, that will prove it, too. Even if the whole project fails, it won't be possible to blame Verisign, as they tried so hard. Versiign will come out of EV smelling of roses, in all eventualities.
Can you say "barrier to entry" ? The document bears this out:
What then to do? *Mid-tier CAs* should not do it (or more politely, sit on the fence and state that they are implementing the good bits). It makes no sense to spend that money, risk the company, and fail. Or even succeed: there is no future in being the 2nd best after Verisign in a game Verisign designed.
*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 colours purple, peach and turquoise.
As long as the browsers maintain an *open market* in governance models -- something which is written into Mozilla's policy, for example -- there is absolutely no reason for the rest of the world to get our collective knickers in a knot. Ask the browsers to accept the colour purple as meaning a our standard, and go out and market it. If and when EV fails, we can simply pick up the good bits and redo it. Which should appeal to everyone, as they get the best bits for free.
For *public policy* again the answer is "do nothing." It was suggested by one insider that the CAs are really worried about anti-trust. This is nothing more than a bunch of naughty schoolboys hoping not to be caught smoking in the toilets, it's far and away an unlikely target for anti-trust. As long as there is free entry into the market for browsers and web servers, there will be no great ability for a group to take control. If EV becomes a danger, we can write software to bypass it (as everyone has to do with browser security at the moment due to phishing).
Posted by iang at November 12, 2006 11:54 PM | TrackBackthere 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.
Posted by: Peter Williams at November 13, 2006 12:39 PMPKI has always been tying scheme (a smart contract that forces you to buy additional services to get crypto) sold as a security scheme.
Posted by: nick at November 16, 2006 01:16 PMA 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!?
Posted by: Eddy Nigg at February 15, 2007 07:57 AM