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.

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):

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.