So, how does the revocation notification get propagated? Certificates come attached to all kinds of mobile objects ranging from signed forms to ActiveX controls, so considerable thinking has been put into how to avoid having revocation notices chase certificates. These include simple techniques like issuing certificates with short validity periods (certificates just expire on their own), directory-based revocation certificates (in effect an ``anti-certificate'') and online status checking. While each of these approaches may reduce the problem to some extent, they all rely on two independent but closely related factors:
Technically, the ``revocation mechanics problem'' boils down to on-line vs. off-line operation and open vs. closed systems. In the traditional closed, on-line system, for example within an enterprise, a trusted directory is the obvious repository for key status information. But how realistic is this model in the long term? Gartner [3] estimates that by 2001, 60 million users will be relying on intermittent, low bandwidth, unreliable network connections and notebooks continue to be the fastest growing segment of the PC market? Furthermore, in the age of the Internet where are the examples of truly closed systems?
Possibly the only large-scale specimen of a closed system is the bank credit card authorization network within the United States, and in its Internet implementation (SET), there is currently no support for revocation. It has been argued that SET does not need a revocation mechanism because a SET certificate is just a proxy for a credit card that exists in the physical world. Only the account number requires verification -- and legacy systems work fine for this task. Thus, if the rest of public key systems are trending towards all open and often off-line in their degenerate state, we have to make some form of revocation work within those constraints.
The most common proposed method for distributing revocation information requires an issuing certificate authority to publish a signed list of revoked certificates (a CRL). These lists may be actively distributed to users or simply made available to interested applications via cached file references, URLs, or directory queries. In any case, it is up to the individual application to determine whether it will enable CRL checking by default and how it will handle revoked certificates. In practice, applications that must rely on HTTP do not generally check CRLs by default for performance reasons, and even when such applications do perform revocation checks they only warn users of revoked certificates. These are two separable problems.
Applications' not checking for revocation should not be wholly credited to some fear of degraded performance. Robust revocation information just isn't available yet and, more importantly, the legal landscape isn't littered with case law allocating liabilities for misinformation. After all, revocation of a certificate only means that either one of the two parties chose to terminate the binding of the public key to some identity or authorization.
A possibly larger issue is timeliness. There is no magic in how revocation data gets to a client in an enterprise setting: it's either a signed wad of certificates or their hashes pushed at some designated time, or, if he happens to be online, the client can fetch it. In either case, there is some amount of latency. Revocation is after all a process, not an event, and as such implies some responsibility (if not outright liability) for correctness. Due diligence requires the expenditure of time and effort somewhere in the system.
Perhaps the whole certificate revocation concept itself is too blunt an instrument to be really useful without some re-engineering. While PKI architects are worrying about hundreds of millions of certificates floating around, systems designers are trying to figure out how to ``recall'' individual Java applets without impacting code size or runtime overhead. Revoking a software publisher's certificate clearly doesn't solve the problem.
Dealing with revoked certificates presents another set of problems for applications. When a revoked certificate is encountered, can an application simply prompt the user for a decision, or must it invoke some policy to determine what to do? There isn't a definitive answer yet; the only widespread applications that actually use certificates are secure channels and mail. In fact, the only people talking about public key infrastructures these days are technologists and lawyers; the business types haven't shown up yet to the party.
When those business types do arrive, though, the applications in which they will most likely be interested deal with something everybody cares about: money. Signed transactions with assigned monetary value and properties of non-repudiation are the obvious next step to legitimacy for public key systems and the certificates that support them. Revocation will begin to mean something.
The credit card system provides both bad and good examples of how things could work. Bad because the issuer of the ``certificate'' (aka the credit card) is always a party to any transaction using it, and because the certificate remains the property of its issuer (which means he can govern its use through subscriber agreements). For example, the card cannot legally be used for identification (cashing a check) and no other identification (a driver's license) may be required by a merchant to accept it.
Credit cards provide a good example because the card itself is only a small component of a complete (and highly mature) risk management system. When a merchant goes online to authorize a credit card he not only associates a value and a signature with a transaction, but he simultaneously sells his own risk to his bank for a fixed discount rate. His bank, in turn, sells that risk to the card's issuer or assumes it himself (which, by the way, is the default outside the US where communication costs are high). As soon as the merchant makes the decision to authorize the transaction, he's committed to sell it. The same holds true for his bank. In each case, though, the decision to sell the risk (i.e. go online) is the decision of the risk holder.
The critical point here is that the transaction is being traded (i.e. bought and sold) between cardholder and merchant, between a merchant and his bank, and ultimately between banks. Each participant in the value chain discounts, or more precisely, factors it. The only difference between the certificate acceptance model and the old credit card acceptance model is that the risk metrics of the latter are built on years of experience with billions of transactions.
So, how does risk management relate to public key certificate revocation? It's possible that the controversy surrounding such basics as whether certificates state the right relationships for keys, who should be trusted to issue and revoke them, and how far that authority extends will go on as long as there are no risk models in place to test the assumptions. If the credit card system is any indicator of how public key infrastructures will actually roll out, then revocation will start with a simplistic blacklist like the ``card recovery bulletin'' and evolve based on something as fundamental as who's willing to pay for revocation information. The value of the transaction, or rather the effect of fraud, will determine whether it is verified off-line or on-line and what kinds of checks are performed.
In terms of the revocation data, credit card companies price this kind of information based on the risk characteristics of the individual transaction. For example, a bad merchant could be blacklisted for free because that information benefits the entire infrastructure, but individual cardholder status costs something. Again, it's all about risk. For certificate revocation lists, this would imply that revocation lists and online status checking of individual certificates would be available at different prices - but in no case free!
The core question then resolves down to, ``To an acceptor, does a certificate have any independent value, or does it rely on his trust in its issuer?'' Who is trusting whom? When the issuer is a party to the transaction, a certificate can certainly provide authentication along with some form of authorization. What's more interesting, though, is what happens when the issuer is not a party to the transaction. Will the acceptor of a certificate pay any attention to what an issuer intended as its use when issued, and does the acceptor even care that the stated binding is still valid?
It is still too early in the process of gluing public key infrastructures together to predict how relying third parties will view their relationships, real or implied, with certificate issuers. As we saw with credit cards in the seventies, it all resolves to a ``certificate acceptance'' problem. And this is the tough infrastructure play.
In a world where certificate issuers acquire some reputation (through a brand even?) then it might follow that the possession/revocation of a particular certificate carries more weight than the possession/revocation of another. Likewise, having ten certificates against a single signature key could pass for some form of digital credit rating. Sound familiar? If we're actually facing the digital variant of a known risk model, then elaborate infrastructures will almost certainly grow up to support certificate revocation and every intermediate state on the way to it.
The most obvious of these is aggregation of certificate-linked information into some ``universal'' revocation service paid for by the at-risk stakeholders. The Visa and Mastercard associations are existence-proofs of this concept at work for banks, but it's not clear that banks are going to be the only risk stakeholders in PKIs. Key-holders of all kinds, along with certificate acceptors, may well pay for some trusted, instant, and always available revocation registry -- but only if the risk profile of the transactions justifies its cost.
This kind of service would undoubtedly have to offer more than notice of revocation. The real value in the credit card authorization network is that it provides fraud detection as well. If it's worth the trouble for a crook to compromise a signature key, then he's bound to use it in transactions. How can these be detected and what accompanying consumer protection must be in place?