The business of CAs

As I mentioned in my previous post about the new policy on CA certificates, one major issue is to what extent we should distinguish among the different types of certificates issued by different Certification Authorities, both in terms of the policy and also in terms of the SSL/TLS UI used in Firefox and other products. In today's SSL/TLS certificate market CAs sell certificates with different claims as to the "assurance" of the certificate, but Firefox and other browsers have a "one UI fits all" approach, where any SSL/TLS connection to a web site receives the same UI treatment (the infamous padlock) regardless of how and to what extent the CA validates the holder of the site's certificate.

After many years of the status quo there are now forces operating that may change this situation. I think that in order to understand the issues around the SSL/TLS UI we have to look not only at the security-specific issues (e.g., the nature and severity of threats, and the mechanisms by which we might defend against them), but also at the environment in which CAs are likely to be operating, and how their role might evolve over time based on the likely forces of change that are present in that environment.

By the title of this post--"the business of CAs"--I mean both "the functions that CAs serve", in the sense of what the role of a CA is or should be in the context of securing computer systems and applications, as well as "CAs as businesses": What markets are CAs serving? How big are those markets? What forces are operating in these markets, and how do those forces affect competition among CAs? Are there markets not being served by CAs that could be?

I focus specifically on the topic of CAs issuing certificates issued for SSL/TLS-enabled web servers, because this is both the most noteworthy application of CAs today (at least as far as the typical user is concerned), because it is associated with the problem of phishing (probably the most prominent security threat associated with web browsing today), and because what happens in this area will likely determine how the business of CAs might evolve in the future.

The functions that CAs serve

Regarding the functions that CAs serve, as I see it there are at least four possible views as to what CAs do (or should do):

  • Enable encryption. In this view the primary function of CAs is simply to enable web servers to be configured properly to support encrypted connections from browsers to servers using the SSL or TLS protocols. The proposed role of the CA is simply to sign the public key associated with the server's private key, with the use of a public CA to do this just an alternative to using a self-signed certificate or a "do it yourself" CA. According to this view an end user surfing to (say) "https://www.example.com" should simply expect the connection to be encrypted, with minimal or no guarantees beyond that. (People holding this view do acknowledge the theoretical possibility of "man in the middle" attacks but dispute their relevance to typical web users, pointing to the apparently successful use of self-signed certificates with SSH and similar protocols.)

  • "Fix" DNS. In this view the primary function of CAs is to prevent man-in-the-middle attacks and related problems arising from the lack of security measures in the current domain name system. The proposed role of the CA is to verify that an SSL/TLS certificate for a server with a given domain name is issued only to the entity (person or organization) controlling that domain. According to this view an end user surfing to "https://www.example.com" should have a reasonably good assurance that they are in fact connecting to www.example.com and not to another site run by an attacker using techniques like DNS cache poisoning to masquerade as www.example.com.

  • Verify identity. In this view the primary function of CAs is to prevent attacks arising from users' confusion about the real-world identity of the entity operating a web site. The proposed role of the CA is to determine the "true identity" of the entity operating a web site, and to attest to that identity through inclusion of identity information in the digitally-signed certificate issued to the site's owner. According to this view a user surfing to "https://www.example.com" should be able to determine (to a reasonably high degree of assurance) that the site is operated by (say) the real-world company "Example Widgets, Inc.".

  • Prevent fraud. In this view the primary function of CAs is to protect users from inadvertantly using web sites set up for fraudulent purposes. This is similar to (and often confused with) the "verify identity" function, but here the proposed role of the CA encompasses not only determining the "true identity" of a web site operator (whatever that might mean) but also making some determination as to whether the operator might be engaged in fraudulent activities, and hence should be prevented from obtaining a certificate in the first place, or prevented from further using a certificate already obtained. According to this view a user surfing to a URL like "https://www.example.com" should have a fairly high level of confidence that the site operator "Example Widgets, Inc." is a legitimate business and not simply a front for criminal activities.

Each of these views of a CA's proper function has implications for the type and nature of the work that CAs have to do when issuing certificates to applicants. For example, demonstrating that an applicant for a certificate owns and controls a particular domain name is more straightforward than also trying to validate their real-world identity, which in turn is more straightforward than determining whether an applicant might have criminal intentions or not.

This in turn has implications for the cost structure of CAs as businesses, and the potential size, profitability, and other characteristics of the CA industry in general. One's choice of view also has implications for how browsers and other applications might use CA-issued certificates and the information contained within them, and for how suppliers of certificate-enabled applications might work with CAs.

CAs in the past

To understand the future we first need to look at the past, and how we got to our present state. SSL as originally implemented and deployed had the following chacteristics:

  • Although the SSL protocol allowed for the possibility of both web servers and web browsers having public key certificates, the protocol required only that servers have certificates. This in my opinion was the key to SSL's success, because it was in sync with the business environment of the web and the economic incentives of the various parties involved: web users had no incentive to pay the cost in time and trouble to obtain certificates, but operators of web sites (particularly the e-commerce sites to which SSL was promoted) could easily justify obtaining certificates as a cost of doing business. (Even a USD 1,000 server certificate was cheap compared to the costs of setting up an e-commerce site in the early days of the web.)

  • In order for SSL connections to work, browsers needed a set of root CA certificates to validate any SSL server certificates that might encounter in users' web activities. End users didn't have to worry about acquiring this set of root certificates, since the browser vendors conveniently pre-loaded the necessary certificates in the browser software itself. Thus just as users didn't have to worry about obtaining client-side certificates, they also didn't have to be aware of the existence and functions of CAs.

  • The primary visible indicator exposed to users in the browser user interface was the padlock icon (closed for a web page retrieved through an SSL connection, open or absent otherwise), which hid the underlying complexity of certificates and CAs.

At the time that SSL was created and for some time afterward, the CA market had the following chacteristics:

  • There were relatively few commercial CAs, and their market strategies, business practices, and cost structures were oriented around the presumption that their primary function was to verify identity in the context of electronic commerce transactions, not just in the context of SSL but in a wide variety of PKI-enabled e-commerce applications that were projected to emerge.

  • Some browser vendors (most notably Netscape) charged CAs fees (sometimes quite substantial) to have their root CA certificates pre-loaded with browsers.

The browser vendors thus in effect became the gatekeepers for CAs that wanted to sell SSL server certificates. On balance controlling such an "authorized CA" list was necessary given the underlying SSL/PKI model. However the result was that Netscape, Microsoft, and other browser vendors distorted the CA market by limiting competition, and in consequence CAs could and did charge relatively high prices for certificates, prices justified by CA's presumed role as validators of the identity of certificate subscribers.

However at the same time the end user perception of CAs and certificates was based on a "one UI fits all" user interface that made no distinctions between CAs, at least in terms of the default UI seen by most users (i.e., the padlock). This perception in turn influenced the customers of CAs, namely web site operators: their primary goal was to be able to configure their site to present the expected SSL/TLS UI indicator (the closed padlock) to end users.

This contradiction between CAs' own perception of themselves and their customers' and end users' perception of them set the stage for a disruption of the market for SSL/TLS server certificates, as described in the next section.

Disrupting the CA market

One good way to understand the changes in the CA market is through the lens of Clayton Christensen's theory of disruptive innovation. In Christensen's terms CAs "overshot" the needs of their primary customers, the operators of e-commerce sites and other SSL/TLS-enabled web sites: They were paying for product characteristics (in particular, presumed validation of identity) that were not perceived as valuable by end users, and hence were in excess of the actual needs of web site operators.

This then presented an opportunity for new market entrants to employ a low-cost disruptive strategy: provide a product with lower intrinsic "performance" and correspondingly lower cost, in an attempt to take market share away from incumbent providers and also perhaps grow the overall market, by attracting new customers previously unable to afford the dominant product offerings.

The particular "performance" measure of interest in this case was the degree to which a certificate was presumed to validate an actual real-world identity. New market entrants could and did reduce the use of manual procedures that purportedly served to validate real-world identity, e.g., having certificate applicants fax in business licenses or other documents for manual review. They replaced them with procedures that could be more automated, e.g., verifying ownership of domain names (by sending automated emails to the listed contact for domains and doing automated processing of the responses), doing automated cross-checks against on-line databases of businesses and individuals, and so on.

At the same time the CA market became more standardized and open: Browser vendors dropped the practice of charging for inclusion in the list of pre-loaded CA root certificates, and substituted use of relatively standard criteria, for example requiring only that CAs be audited as part of the WebTrust program for CAs.

The general results of these trends can be seen in the relative market shares of CAs, as reported in the most recent report on SSL/TLS certificate use provided by E-Soft at their securityspace.com site: The market for SSL/TLS certificates has moved from being dominated by a single vendor to a situation where a number of vendors compete on a relatively equal basis, with price presumably being a major factor in that competition.

Historical CA market share across all domains

At the same time the overall market for SSL/TLS server certificates has grown steadily but not spectacularly, and may be levelling off (again, these figures are courtesy of E-Soft, and are for the November reports of each year):

Year Total certificates Growth Valid certificates Growth
1998 81,169 n/a 8,456 n/a
1999 59,914 -26.2% 11,413 35.0%
2000 57,030 -4.8% 14,534 27.3%
2001 63,761 11.8% 20,696 42.4%
2002 98,718 54.8% 43,779 111.5%
2003 154,477 56.5% 65,017 48.5%
2004 192,625 56.5% 81,262 48.5%
2005 220,756 14.6% 91,182 12.2%

In my opinion the actual size of the commercial SSL/TLS server certificate market is best estimated using the number of valid certificates, i.e., certificates that are issued by a known CA, have not expired, and match the domain name of the host on which they are deployed; each of these certificates represent actual revenue to some commercial CA, whether such certificates were sold for each individual server or otherwise (for example, so-called "wildcard" certificates that can be used with any server in a given domain). (Note that we ignore as minimal whatever small fraction of certificates are issued by government-affiliated or nonprofit CAs.)

The current market for SSL/TLS certificates is not very large: Current certificate prices range from approximately USD 15 per year up to several hundred USD per year. If we assume an average price per SSL/TLS server certificate in the range of USD 100 or so per server per year, then the total market for SSL/TLS server certificates at present is on the order of USD 10M per year, with a potential market perhaps twice that.

The survey data also provide an idea of the business prospects for a new commercial CA issuing SSL/TLS certificates for web servers on the public Internet: Beyond the top few CAs no other CA has more than one per cent market share or issued more than a thousand or so certificates. For a new entrant to the market, issuing certificates to a few hundred servers times at USD 100 per server per year equals annual revenue of USD 100K at best.

The future of CAs

How will the commercial CA market evolve in the future? In Christensen's terms there are multiple possibilities to look for:

  • Low-cost disruption continues and the CA market becomes commoditized, with profits moving to another part of the value chain.

  • Incumbent vendors try to move up-market to preserve their current business models and pricing.

  • A new-market disruption occurs, where innovative CAs support new applications not currently possible.

We can obtain more insight into these possibilities by going back and considering the four possible views of CAs' functions described above, together with how these views might interact with possible changes to browser UIs and other factors.

CAs as encryption enablers: Expanding the market or not?

If we adopt the view that CAs primarily exist to help enable the use of encrypted connections then the use of CA-signed certificates can be viewed simply as a natural "upgrade" from using self-signed certificates (as, for example, Ian Grigg has argued). In this view browsers should and would be changed to automatically accept the use of self-signed certificates in the context of SSL/TLS connections, albeit perhaps with some minor difference in UI versus CA-issued certificates, and web servers and other servers would be configured to automatically generate self-signed certificates and enable them for use. The hypothesized result would be a major expansion in the number of sites that are SSL/TLS-enabled, expanding the possible market into which CAs could sell certificates.

However another possible scenario consistent with this view is that CAs might fail to convert any significant portion of these newly-enabled web sites from using self-signed certificates, because the incentives would not be not great enough to get "real" certificates; CAs might pick up some incremental business, but overall the SSL/TLS server certificate market might remain roughly as it is today.

At the same time, in new high-growth markets outside the traditional web context public commercial CAs as such might be absent altogether, replaced by the use of either self-signed certificates or "private" CAs invisible to the user; an example of the latter is the PKI technology embedded within the Skype voice over IP client. (Today's public CAs might participate in these new growth markets, but not as public CAs, instead being subcontractors providing CA services or technologies to others.) As it happens, this sort of "invisible CA" approach is exactly what we might expect to see from a vendor like Skype pursuing a new-market disruptive strategy: One key to successful new-market disruption is simplicity, which expands the potential market to less technically-knowledgeable users, and simplicity is most easily achieved through an integrated solution that hides complexity from the user, including the complexities of directly dealing with CAs.

CAs as DNS fix: Commoditization followed by integration?

The view that the primary function of CAs is to provide additional security for the DNS matches up well with the low-cost disruptive strategies of new entrants to the CA market, almost all of which focus primarily on validating domain name ownership through automated means as opposed to performing manual procedures to verify real-world identities. This view is also most consistent with the SSL/TLS UI in the current versions of Firefox and other browsers.

In this scenario the CA market would become commoditized, CAs would become low-margin businesses, and any profits would be found elsewhere in the value chain. One possible result is that the CA business would become simply a component of the larger domain name registry business, which would in turn become simply a component of the overall web hosting business. Success would then go to those companies that could most successfully and profitably put together integrated web hosting offerings that offer "one stop shopping" for web hosting, domain name registration, SSL/TLS certificate issuance, web "storefront" creation, back-end payment processing and related services, and so on, all offered on a self-service basis enabled by extensive automation--basically the Dell model as applied to the "web presence" business. Here again some or all of today's public commercial CAs might morph into new forms, becoming subsidiaries of or subcontractors to integrated web presence providers.

CAs as identity validators: A viable up-market strategy?

The view that CAs exist to validate real-world identities, if truly taken seriously, would naturally lead to an attempt to essentially "reboot" the CA market to try to return it to its original roots. This would likely require stronger and more consistent requirements on CAs purporting to validate identity (for example, through new independent standards or guidelines incorporated into CA audit programs like WebTrust), combined with modified browser UIs to highlight the use of new "higher assurance" or "enhanced validation" certificates issued by CAs meeting these requirements.

In this scenario incumbent CAs could attempt to escape the effects of low-cost disruption by moving up-market into the new "enhanced validation" space, preserving their ability to charge higher prices for a product offering that offered enhanced "performance" to their customers (operators of e-commerce sites), namely the ability to show end users new UI indicators advertized as being associated with increased security for user transactions.

However since CAs in this scenario would be operating within a standard set of guidelines as to acceptable CA practices they would still be in danger of falling victim to commoditization, where CAs would be perceived as offering relatively undifferentiated services with limited ability to command a price premium relative to other CAs offering similar services.

CAs as fraud preventers: A way to create effective brands?

As mentioned previously, the view of CAs as existing to prevent fraud is confused with but distinct from the view of CAs as existing to validate identity. In the context of this discussion, redefining the CAs role as preventing fraud offers up the possibility of CAs differentiating themselves in ways that are not possible when CAs are simply attempting to conform to common guidelines (as in the previous section).

However in order for this to happen at least two things need to occur: First, though this may seem obvious, CAs would actually have to do something concrete about preventing fraud and/or mitigating its effects, something which would have a real positive effect on end users (and thus would attract web site operators who have an interest in keeping end users happy). Unfortunately the marketing messages put out by CAs (particularly the extensive use of the word "trust" in corporate names, slogans and elsewhere) have sometimes conveyed a promise that goes beyond the reality of CA practices and the fine print of CA policies and legal agreements.

Second, in order to be able to differentiate themselves in the eyes of users and web site operators CAs would likely want and need more extensive foregrounding of their brands in the browser UI and related places. Only by building truly known and respected brands would CAs be able to command premiums above the price levels that would be present in a commoditized market. Reasonable people can differ on whether users would actually be aware of or care about CA brands, but certainly if the present UI situation continues we'll never get the chance to find out.

CAs face one more hurdle in this scenario: The problem of preventing online fraud is bigger than the problem that CAs have addressed or can address; in particular, CAs are of limited relevance in the current fight against phishing, because very few phishing attacks currently use SSL/TLS-enabled sites. This means that CAs in and of themselves can't offer a complete solution to the problem of preventing online fraud, and this in turn means that user brand awareness around online fraud prevention may accrue not to CAs but rather to providers of more comprehensive anti-phishing measures, whether they be browser vendors like Microsoft or third-party providers like Netcraft.

That concludes this post; my apologies for the length of it, and my sympathies to those of you who managed to struggle through to the end. In a future post I hope to write more about the specific issues of the SSL/TLS UI in Firefox and what (if anything) we might want to do about it.

Comments

Iang wrote at 2005-11-21 18:53:

This is a welcome development. I think this rates as a first where a PKI user organisation has come out and presented the unified tuple of {phishing, PKI, problem!} altogether in one context.

One issue I have is that of _the goal_. A lot of the essay while fine and well balanced seems to lead from the pov of what the business structure and interests of the CA is. Sure, fine, but so what? At what point did Mozilla in either its old form or its new form decide it was interested in the wellbeing of CAs?

The point of a browser is to serve the browsing needs of the user, and it is this lesson that Netscape forgot which got us into the mess in the first place, a decade ago. The point which should be decidedly clear to any browser manufacturer is that furthering the commercial goals of commercial CAs, which for most purposes and places are to sell as many certs as possible and not get caught out, is probably not in the users interests. (Even if we drag in those other oddballs like CAcert, its hard to merge these interests with the PKI structure being so asymmetric.) You may have a double challenge in front of you as you have to draw the line from CAs' interests to users' benefit, something that CAs have never made easy.

Of course, this is a bit unfair as Mozilla hasn't really thought through its goals beyond the very basic notions of "give users a choice in browsing ... quality of experience ..." two metrics that are either already achieved or vague and therefore not goals. And it certainly hasn't a security goal. Still, maybe the point is to show how little users are benefitted by the current situation, and how things can be improved. Good luck.

Tsee wrote at 2005-11-21 21:13:

I really like your post on CAs. It made me think about how I use the padlock icon; I think it implies to me encryption and DNS security. I do think it's useful to analyze the CA market as it'll affect the effectiveness of any Mozilla policy regarding their certificates.

I'm not sure, however, if it's possible or even advisable to pursue fraud-prevention as a goal of CAs. Even a legitimate business can easily screw a customer, as BBB and personal experience will surely testify. I mean, I consider myself a very smart customer, but I found myself recently a victim of NetZero, of whom I'd had a very favorable impression.

After signing up for a Netzero 3G trial, I discovered that heavy usage of the network is discouraged by disconnection about three hours after a connection. That would not do for me, even in a place that is not my home. So I called to cancel. I was offered two more months of free service, so I asked specifically if I would not be charged if I were to call before the period was up. I was promised so, but found my credit card billed twice by October. I called later that month to complain and was told that "this isn't how we do business." I was promised a refund for both charges of $9.95. Not seeing any credit on my account, I called earlier this month and was told that no refund would be given at all. Basically, I was lied to twice.

Fortunately, I'd started the dispute process with my credit card company, which I believe NetZero's delaying tactics was designed to deflect. Could a CA have prevented this episode? I don't see how.

Ian wrote at 2005-11-22 04:50:

Excellent post.

Perhaps we could alternately do something like 'gold' grade for CA's that really verify that the sites are real companies etc, and 'silver' for regular encrypted connections. Mozilla/some standards body would then have to set minimum requirements to be 'gold'.

Damjan wrote at 2005-11-22 14:26:

There's one thing I don't understand. Say I have a certificate from some CA (Thawte, Versign, etc..), caqn I use that certificate (and it's key) to sign my own sub-certificates.

How will Firefox report those?

Frank Hecker wrote at 2005-11-22 17:22:

To Damjan: In order to sign certificates you need a private key; however the certificate itself contains only a public key. So if you have a certificate from a CA you can't sign your own "sub-certificates", because you don't have the CA's private key. (In a well-run CA signing keys are closely protected, typically by having them kept on a special secure hardware device on which signing operations are done.)

Will Kamishlian wrote at 2005-11-23 08:33:

Given the current climate, I do not see CA's moving far beyond encryption and DNS validation. It also seems to me that DNS validation is more of a UI issue. Phishing tends to take advantage of URL spoofing rather than DNS spoofing, and URL spoofing can be caught by browsers and email clients.

On the other hand, I think our current CA's could move toward premium services in the arena of fraud prevention. The issue here is that each CA, in addition to related organizations (Better Business Bureau, etc.), are operating independently, and each has their own label and practices. CA's could create basic fraud prevention were they to compose a consortium with financial agencies and other organizations. Such a consortium would establish rules for identification, verification, underwriting, etc. as a means to standardize fraud prevention on the Internet. The result would be that CA's could create a standard "union label" that users could easily recognize -- something akin to the locked padlock that we now use for SSL.

Most users would be able to understand the difference between the two symbols. The padlock would stand for security, and the new symbol would stand for added fraud prevention. Thus, such a scheme would add to users' understanding of Internet security. Failing such measures, government is going to intrude further into this arena, and the consequences will likely be as suboptimal as those in the DRM arena.

Ian wrote at 2005-11-23 10:07:

I assume that as you have this position at Mozilla you were involved/know about this, but if not, this was very interesting indeed:

http://dot.kde.org/1132619164

Regarding IE/Moz/Opera/Konqueror getting together to discuss security, this was mentioned:

1. The location toolbar becomes a permanent UI fixture along with the status bar 2. The padlock goes into the location combo-box permanently, is the only place it appears, and the location bar stays white by default 3. When verification on a site fails, the location bar is filled in red 4. When a high-assurance certificate is verified, the location bar is filled in green, the organisation name is displayed beside the padlock, and it rotates displaying the name of the CA

Frank Hecker wrote at 2005-11-23 10:26:

Re the KDE.news article, I did see it and in fact I was involved in the discussions referenced; I'll be blogging more about this topic later today.

One very important point: Whatever you might read or hear about "browser vendors all agree", note that I haven't made any commitments on behalf of the Mozilla project, nor do I have the power to do so. I can only make suggestions; final decisions on the UI for Firefox, Thunderbird, etc., are up to the development teams for those products.

Will Kamishlian wrote at 2005-11-24 14:27:

Given the current climate, I do not see CA's moving far beyond encryption and DNS validation. It also seems to me that DNS validation is more of a UI issue. Phishing tends to take advantage of URL spoofing rather than DNS spoofing, and URL spoofing can be caught by browsers and email clients.

On the other hand, I think our current CA's could move toward premium services in the arena of fraud prevention. The issue here is that each CA, in addition to related organizations (Better Business Bureau, etc.), are operating independently, and each has their own label and practices. CA's could create basic fraud prevention were they to compose a consortium with financial agencies and other organizations. Such a consortium would establish rules for identification, verification, underwriting, etc. as a means to standardize fraud prevention on the Internet. The result would be that CA's could create a standard "union label" that users could easily recognize -- something akin to the locked padlock that we now use for SSL.

Most users would be able to understand the difference between the two symbols. The padlock would stand for security, and the new symbol would stand for added fraud prevention. Thus, such a scheme would add to users' understanding of Internet security. Failing such measures, government is going to intrude further into this arena, and the consequences will likely be as suboptimal as those in the DRM arena.

Damjan wrote at 2005-11-28 13:49:

"In order to sign certificates you need a private key; however the certificate itself contains only a public key."

Sorry to bother you, but don't I need the private key on the server too, to establish a SSL connection? The SSL client receives the certificate containing the public key, it validates it against the root CA's. But the server sends stuff encrypted with its private key? Or not?

Frank Hecker wrote at 2005-11-30 11:32:

To Damjan: You're correct, the server does have a copy of the private key corresponding to the public key in the server's SSL certificate. However that private key can't be used to sign certificates. Or, more correctly, it could be used to sign certificates, but no browser would recognize such certificates as valid. To create valid certificates (i.e., certificates that would be recognized by browsers) you would need the private key for the CA, i.e., the private key corresponding to the public key in the CA's own certificate.

John P. wrote at 2005-12-12 06:27:

Your analysis of the CA market gives short shrift to the issue of the lack of functionality in the browser.

If you look at the market share graph, you see that Verisign's market share slide started long before Geotrust started up and the decline barely changed after Geotrust (though Thawte, a unit of VRSN by then, did start to drop).

So, the automation and commoditization really didn't have that big of an impact on market share. I believe the lack of functionality in the browsers to make SSL certs useful for the other functions you list is what really caused pricing to drop.

Basically, SSL had two useful purposes: (1) enable encryption for login, because at the time it came out we *did* have password sniffers showing up at ISPs; and (2) provide a false sense of security to help convince people it was safe to transact online.

Glad to see the discussion is happening about what standard functions should be implemented in browsers to change this.

Submit a comment

Please enter comments as plain text only; no HTML tags are allowed. All comments and trackbacks are moderated, and will not be displayed until approved by the moderator.

Comments are closed for this story.

Trackbacks are closed for this story.