Bob Walder
The NSS Group
TechOnline

With the growth in use of the Internet for business transactions, the need for confidentiality and positive identification of all parties involved is increasingly vital.

The use of encryption and digital signatures are important tools in the ongoing struggle to maintain privacy and confidentiality over insecure transports such as the Internet. Public key cryptography is the perfect solution for ensuring the privacy of data employed in distributed systems of all kinds. This is especially true in the kinds of systems implemented as part of e-commerce solutions, where organizations are engaging in transactions with individuals who are hitherto unknown to them, and with whom they may never have any further contact.

The cost of deploying secret keys for such transactions is high, both in pure financial terms and in terms of the loss of a large number of customers who would not have the patience to wait for some sort of secure key distribution to take effect. Internet shopping is often about spur-of-the-moment purchases and instant gratification, after all.

Public key systems, on the other hand, allow us to communicate securely between individual and organization using keys which can be freely distributed and published anywhere—much like your telephone number in a directory. This can be augmented still further by the use of digital certificates, which bind a public key to an individual or organization and carry the signature of a trusted Certification Authority (CA), thus verifying its authenticity.

Secure Sockets Layer (SSL), Secure/Multimedia Internet Mail Extensions (S/MIME), Secure Electronic Transactions (SET), and code-signing services for both Java and ActiveX all make use of public key encryption, and thus all require some means of managing those keys. To date, most use of public keys has been driven from the client end—end-users obtaining Class 1 certificates from organizations such as VeriSign for their browsers or e-mail clients.

Application and renewal of such certificates and their associated keys are entirely under the control of the client, and renewal is more a commercial event than a strategic one. For instance, VeriSign forces a refresh of a certificate every year purely to collect fees rather than as a means to force key updates.

A properly implemented Public Key Infrastructure (PKI) supported by an effective security policy will force key updates at regular intervals that will be driven entirely by the security needs of the organization rather than any overriding commercial decision. That key update will also be completely under the control of the PKI administrator or security officer.

Key management imposes a significant burden on an organization, since it requires far more than just a piece of certificate server software to create and distribute digital certificates. To date, however, many organizations have found it confusing when looking for products. Is CA software the same as PKI? Are there any standards in place? Do they need separate directory services?

It's true that to date standards have been pretty thin on the ground, leaving companies to hang fire or settle for one of the widely available—yet essentially proprietary—PKI systems. The rapid adoption of the Internet as a business communications medium, however, has accelerated the requirement for robust and effective key management systems and PKI is suddenly under the spotlight.

Most certificate products, however, are focused primarily on the creation, publication, and management of certificates. Products such as Netscape Certificate Server and Microsoft Certificate Server, for example, enable managers to generate "root" keys used to sign the certificates they generate. Both allow details of the certificates generated to be published in a directory and support the use of Certificate Revocation Lists (CRL).

All these are important functions, but stop short of full key management facilities—such as backup, recovery and update—that are necessary to support a full-blown PKI. The astute buyer therefore needs to be aware that certificate generation and distribution is only one small part of a complete PKI solution.

If you are looking for that complete solution, you should expect the products on your short list to contain most, if not all, of the following components:

1. Certificate Server—This is the platform that generates, serves and manages the certificates and binds them to the appropriate public keys—both for signing and encryption. It will also renew these on demand or at regular intervals as defined by security policies. Note that private keys are not held at the server in order to provide non-repudiation (see point 7).
2. Directory—A repository of all the public information that is pertinent to a PKI, including the public key certificates, CRL, ARL, CA certificates, and so on. It is critical that this element of the PKI has high availability, and it is often distributed throughout an organization.
3. Revocation System—The ability to revoke a key to prevent further access to encryption and/or signing functions by the user using a particular key pair (perhaps because the user has left the company or because his or her keys have been compromised in some way). Certificate Revocation Lists (CRL) must be maintained automatically and distributed regularly throughout the system to ensure that access is always restricted only to those with valid certificates. It is also important that end-user applications check them, of course.
4. Automatic Key Update—The only reason for a certificate to have an expiry date is to ensure that new key pairs are generated at regular intervals. However, the end user should be completely unaware of this process, unless the security policy dictates that a positive action is required by the user. If a positive action is not required, the key update should be completely automatic and transparent, ensuring that the user is always using keys that conform to the corporate security policy.
5. Key Histories—As keys are updated at regular intervals, it will become necessary to access data encrypted under a previous generation of keys for a particular user (or to verify a signature created with an earlier key pair). The user should not have to keep copies of every version of every certificate and associated key pair they have ever used—matching key pairs to documents would be a time-consuming and error-prone task. Instead, the PKI should provide the means to maintain a complete key history against a user, and should access the appropriate version each time a decryption or signature validation operation is performed.
6. Key Backup and Recovery—Not to be confused with key escrow, key recovery ensures that copies of decryption keys are maintained at the certificate server for all users, and can subsequently be recovered should the need arise (such as when the user forgets a password, leaves the company, or if a court order is produced by a law enforcement agency to recover encrypted data).
7. Support for Non-Repudiation—the idea of key backup and recovery opens a loophole in the system. Now a user could claim that because someone else potentially has access to their signing key, that they were not actually responsible for particular transactions that had apparently been signed by them. It is thus necessary to maintain dual key pairs for every user. The encryption key pair can be backed up and recovered, whereas the signing key pair should never leave the user's possession.
8. Cross Certification—If Bob and Alice work for Acme Inc., they trust it as their Certification Authority. If Fred works for Bloggs Inc., he trusts it as his CA. But how does Bob know whether or not he can trust Fred? In order to remove the need for multiple trusts to be created between individual users, a PKI should be able to create high-level mutual or one-way trusts between CA's. Thus, if Acme trusts Bloggs, then by implication, Bob and Alice can both trust Fred. Of course, Acme and Bloggs must exercise due diligence to ensure that they both have similar risk models and procedures.
9. Client-Side Software—If all of these functions are to be supported fully, then some form of PKI interface is required at the client PC. Only then can the PKI ensure that CRL's are checked rigorously, that key lifecycles are managed correctly, and that key histories are maintained transparently. Of course, some organizations will not want to be forced to touch every single client when rolling out their PKI, and so client-side software will not always be required. In these cases, a pure Web model can be used, though with certain limitations (in other words, no key lifecycle management and limited CRL checking).

Of course, not all of these components are always supplied by the PKI vendors themselves. The most obvious element which may be already installed in an organization or which may be provided by a third party is the directory service. Those using an enterprise X.500 directory or one of the more recent offerings from Novell (NDS) or Microsoft (Active Directory) will require their chosen PKI solution to integrate fully.

Indeed, any PKI product that does not include all of the above components out of the box, should at least provide support for third party options via standards-based interfaces.

Although the mathematics behind it can be very complex, encryption itself is pretty straightforward. Cast your minds back to when you were children and you wanted to send secret messages to each other. The simplest form of encryption was the one where every letter of the alphabet was substituted for the one "n" positions following it.

Here we are introduced fairly painlessly to the two most important buzzwords in the cryptography world: the "key" is the number of positions we are shifting the letters, whilst the "algorithm" is simply the idea that the encrypted letter is the one "n" places following the plain text letter.

There are two ways you can beef up security on this—increase the length of the key, and devise ever more complex algorithms. Luckily, we do not have to get involved in creating our own algorithms, since there are some perfectly acceptable standards out there, the main ones being DES (Data Encryption Standard), triple DES, IDEA (International Data Encryption Algorithm), and RC4 (an algorithm developed by Ron Rivest of RSA as a stream cipher with a variable key length).

Whereas the original DES algorithm uses 56-bit keys, later and more powerful systems use much longer ones, forcing potential hackers to run through trillions of combinations in any attempt to find the right one by brute force. Triple DES is an enhanced version of the original DES algorithm and encrypts data three times using two different keys (providing an effective key length of 112 bits).

There is also an implementation of Triple DES—known as 3DES3KEY—which encrypts data three times with three keys providing an effective key length of 168 bits, though this is much less widely deployed. IDEA is a 128-bit mechanism developed by the University of Zurich in 1992 and is a favorite of European financial institutions.

Now, if we increased the length of the key and wrote it beneath our original message (repeating the key over and over until it was equal to the length of the message), each character in the key would represent a different shift for the letter above.

Of course, if short keys are used, then repeating patterns may begin to emerge in the message—the most secure method is to use a key the same length as the message itself, but this is impractical in real life situations. Combine long keys with sophisticated algorithms, however (something a little more complex than "shift each letter of the message by the value of the key character beneath") and you are in business.

Unfortunately, "secret key" or "symmetric key" cryptography (as it is known) clearly relies on both parties involved having access to the same secret key, since the sender uses the key to encrypt the message, and the receiver uses the same key (together with the same algorithm in reverse) to decrypt the message. This naturally introduces a potential problem—how do we ensure that the key is distributed in a secure manner?

If we have regular contact with the person, we can pass the key face to face—you cannot get much more secure than that. In business terms, secret keys (such as bank PIN numbers) are often distributed by mail in special tamper-proof envelopes, or can be encapsulated in hardware devices such as smart cards, where the issuing authority never gives the customer access to the key information at all.

But in the case of one-off Internet transactions with hitherto unknown parties, we do not have that luxury, since as a result of the unique key-pair arrangement between the two parties, it is impossible to exchange data with someone to whom you have not already been "introduced".

Neither of you has a shared secret key, and there is no secure channel over which to exchange one. For this reason, secret key cryptography works best when a single issuing authority is maintaining a service for a user base where there is some kind of registration process that takes place prior to the exchange of information.

The mathematics behind public key cryptography are exceedingly complex, and beyond the scope of this paper, so you are simply going to have to trust me on this one – any message encrypted with a given public key can only be decrypted using the corresponding private key, and there is no known way to derive the private key from the public key. Honest—this really works.

Now, if Bob wishes to send a message to Alice (Bob and Alice are the cryptography industry's favorite couple), he will encrypt it using Alice's public key (which can be published in a directory or distributed via unsecured e-mail). The only person who can decrypt the resulting message is the holder of the appropriate private key—Alice.

The need for sender and receiver to share secret information is eliminated, since all communications involve only public keys, and no private key is ever transmitted or shared. The best known and most widely used asymmetric key technologies are Diffie-Hellman (for key exchange) and RSA (for encryption and signing).

Although providing the highest levels of security, public key cryptography is notoriously heavy on system resources, particularly when working on large messages. For performance reasons, therefore, RSA is usually used only to exchange keys, whilst a conventional secret-key cryptosystem (such as DES) is used for the bulk of the message.

Suppose Alice wishes to send an encrypted message to Bob. She first encrypts the message with DES, using a randomly chosen DES "secret" key which can be different for every message sent. Then she uses Bob's public key to encrypt the DES key. The DES-encrypted message and the RSA-encrypted DES key together form a "digital envelope" and are sent to Bob. Upon receiving the digital envelope, Bob decrypts the DES key with his private key, finally using the DES key to decrypt the message itself.

In a real-life commerce scenario the most important piece of evidence available to the merchant is the customer's signature. Although it is possible to forge someone else's signature, we have to accept that it is beyond the means of most casual thieves providing the merchant takes sufficient care when checking it.

We therefore require an electronic equivalent—something the merchant can hold up in a court of law and say "here is proof that this particular customer placed the order". Digital signatures—for that is the name of the technology involved—also provide one other useful feature: complete non-repudiation. Not only can we prove that the transaction originated from a particular source, but we can also prove that it has not been tampered with in any way during transit.

To ensure that no one can forge your electronic signature, digital signatures make use of public key techniques, using algorithms such as DSA and RSA (the latter being the most common implementation).

Suppose Alice now wishes to send a signed message to Bob using RSA. She uses a "hash function" to create a uniquely concise version of the original text—known as a "message digest"—which serves as a very much smaller "digital fingerprint" of the message. As with general encryption, there are several secure hash functions available such as Message Digest 5 (MD-5) or Secure Hash Algorithm (SHA-1). After a couple of potential weaknesses were discovered with MD5, SHA-1 has become the preferred method.

It is infeasible that different documents will have the same message digest, and even small changes in a document will cause significant changes in the digest. Next, Alice encrypts the message digest with her RSA private key (or a secret key, if preferred), and this becomes the digital signature, which she sends to Bob along with the message itself (which may or may not be encrypted).

Bob, upon receiving the message and signature, decrypts the signature with Alice's public key to recover the message digest. He then hashes the message with the same hash function Alice used and compares the result to the message digest decrypted from the signature.

If they are exactly equal, the signature has been successfully verified and he can be confident that the message did indeed come from Alice. If, however, they are not equal, then the message either originated elsewhere or was altered after it was signed, and he rejects the message.

Note that for authentication, the roles of the public and private keys are converse to their roles in encryption, where the public key is used to encrypt and the private key to decrypt.

Note also that signing only guarantees integrity and authenticity, it does not guarantee privacy – encryption of the actual message content must be performed separately if required. DSS—developed for use by companies that do business with the U.S. Government—is a signature-only system, whereas RSA can be used both for signing and generally encrypting a message.

Digital signatures provide the highest levels of data integrity, since any tampering after signing invalidates the signature. They also provide unforgeable origin authentication, since they are based on the sender's private signing key, and authenticated by the public verifying key.

Note that in most PKI systems today, two key pairs are generated for each user—one pair for encryption/decryption and the other for signing/verification. This allows the administrator to keep backup copies of users' encryption keys in case those keys are lost or the employee leaves the company and data encrypted with those keys needs to be recovered.

The signing keys, however, never leave the possession of the user (they are never backed up), since they are intended to be as personal—and inaccessible to others—as the user's physical signature.

This is the only way we can ensure non-repudiation, since unless the keys are compromised in some way (in other words, the token on which they are stored is lost or stolen) the user can never claim that someone else signed on his or her behalf.

Since public keys are designed to be readily available, it is difficult to ensure that a particular public key does indeed belong to the person you are expecting, and is not a forgery.

After all, the key is just an apparently random jumble of meaningless data, bearing no resemblance to an actual person and carrying no personal data about the owner. This means that Fred could create a false public key purporting to come from Bob, which he then publishes.

Alice, wanting to send a personal message to Bob, encrypts using the forged public key. The resulting message is useless to Bob, but if Fred can intercept it, he can use his "fake Bob" private key to decrypt the content.

In the "real" business world, when we are about to do business with a complete stranger we may ask for references, or for a third party whom we know and trust to vouch for the stranger.

It would be nice to be able to have similar assurances in the electronic commerce world too, and as it happens we can—using something called a "digital certificate".

This is a small block of data which contains the user's public key together with the a confirmation of authenticity from a third party in the form of that party's digital signature. The third party is the "Certification Authority" (CA) in our PKI, and it is important that the CA is trusted in order that the certificate can be considered genuine. CA's can be either public or private.

An organization operating as its own CA (with its own root certificate) is a private CA, whereas a public CA offers its services to both end-users (say for browser or e-mail certificates) and to corporate bodies who wish to outsource their PKI.

Probably the best known public CA at the moment is VeriSign, though other systems are available such as IBM's World Registry, GTE's CyberTrust, and even the Royal Mail has established a PKI using Nortel's Entrust technology.

As things progress, it should be possible (and desirable) to have a hierarchy of CA's, going from banks or reputable organizations at the bottom, all the way up to government bodies and even, perhaps, the United Nations. The highest certification authority in the hierarchy is known as the top-level CA. Specifically, at the very top of the hierarchy is the root public key. That root public key signs the certificates for all top-level certification authorities, which can then sign certificates for lower-level certification authorities.

This provides the infrastructure for implicit trust between organizations and users without the need for explicit cross certification, since everyone in a trusted community will ultimately trust the same root authority. Until this is established, however, peer-to-peer cross-certification is possible for simple business-to-business relationships.

Depending on the PKI system the key pairs may be generated at registration time, or they may be generated ahead of time and transported to the registration site on a secure token such as a smart card. In a pure Web model, registration is not as stringent (usually tied only to a valid e-mail address and not requiring extensive proof of identity). The keys are then generated locally on the user's PC and a request for a digital ID is submitted automatically by the client-side software (Web browser or e-mail client).

Most public CA's will usually not want to store copies of any of the keys themselves because of liability issues, and will only maintain copies of the certificates. Most private CA's, however, will take a copy of the signing public key and the encryption key pair for backup and recovery purposes. In any situation, copies of the user's private keys always remain with the user and are never transmitted over the network or stored anywhere in the PKI system.

Once she has registered with her CA, Alice is ready for her e-commerce experience. When she wishes to purchase her new PC from Acme Computers over the Internet, she digitally signs the order (she may or may not encrypt it, depending on its sensitivity) and provides a copy of the certificate (this is done automatically in S/MIME applications).

If she wishes, to encrypt the order, she must first obtain a copy of Acme's public key, the authenticity of which she will be able to verify by virtue of the fact that the digital certificate has been signed by a trusted CA (providing the CA's root certificate is held in Alice's browser software).

As a separate operation (or automatically if it is supported by the client software) Acme will check to see that the certificate has not been revoked (the equivalent of a credit card company cutting up your card). Certificates based on the X.509 standard (the most commonly used type) incorporate an expiry date to ensure that certificates and their associated key pairs are renewed automatically after a given period of time.

There also needs to be a system in place to allow certificates to be revoked immediately in certain cases—say where an employee has left the company or the user's private key has been compromised. This is done via a mechanism called the Certificate Revocation List (CRL). The issuing CA can revoke a certificate, thus preventing further use, by adding the serial number of the certificate to a CRL which is published at regular intervals.

How CRL's are made available by CA's varies considerably from CA to CA, and also by how much you are willing to pay for the service! A CA might, for example, have a default policy of publishing CRL's once a day. Institutions which require a more immediate notification of revoked certificates would pay extra for twice daily, two hourly, or even hourly publication. Most CA's also provide a single, monolithic CRL which can be cumbersome to access and slow to check. Some, however, offer more efficient validation protocols such as Online Certificate Status Protocol (OCSP), or a segmented CRL with separate distribution points that is very much quicker to interrogate.

Unfortunately, most applications today do not support automated checking of CRL's even when they are available, and this means that CRL checking must be added to applications that require valid certificates.

Different methods of validation between CA's is yet another challenge of deploying large-scale PKI, though this can be alleviated by using third parties such as ValiCert. ValiCert's Validator Suite has the ability to check the status of any X.509 certificate using any of today's popular validation mechanisms, including CRL's, OCSP, CRL Distribution Points (CRLDP) and ValiCert's own Certificate Revocation Tree (CRT) solution.

Once both parties have satisfied themselves of the other's credentials they can begin trading, safe in the knowledge that they have genuine copies of each other's public keys, and can thus effectively encrypt and digitally sign all future transmissions between them. CRL's must still be checked each time a certificate is presented, however, since the certificate could have been revoked in the mean time.

This provides for complete "non-repudiation", whereby digitally signed messages can be proved authentic to a third party, such as a judge, thus allowing such transactions to be legally binding.

The ability to "extend" a certificate is also inherent within the X.509 version 3 standard, providing the means to hold additional personal information—such as a credit limit or signing authority, perhaps—within the certificate itself (though this raises privacy issues, of course).

In the future—as we move towards an increasingly cashless society—public key certificate details can be stored securely in devices such as smart cards, providing a truly portable and secure (providing you keep your smart card safe) means of performing electronic transactions.

Note that digital certificates are not always associated purely with people—network resources can be allocated a certificate too. For instance, two firewalls could each be assigned a digital certificate with an associated encryption key pair. These could then be used to provide positive identification and encryption capabilities for each end of a Virtual Private Network (VPN) link.

A certificate could also be allocated to a Remote Access Service (RAS) server allowing remote users to be sure they are connected to the correct device, and allowing the RAS server to positively identify each user.

Under the auspices of the IETF, the Public Key Infrastructure Working Group (PKIX) has also created a set of proposals that provide a well-rounded definition of an interoperable public key infrastructure. It is unlikely that the PKIX specifications will displace PKCS, however—the two will undoubtedly coexist and interoperate.

In addition to standards that relate to certificates, there are several that incorporate the use of public key cryptography. These include SSL (Web), S/MIME (e-mail) and SET (credit card transactions). When dealing with SSL it is important to note the version that is supported—version 3 supports client authentication, whereas version 2 does not.

Digital certificates also provide the foundation for SET (Secure Electronic Transactions), a group of standards developed by Visa and MasterCard for Internet commerce, and supported by, for example, Terisa Systems, Microsoft, Netscape, IBM, American Express and VeriSign.

Unfortunately, although most public key applications support the appropriate standards this still does not guarantee interoperability due to slight differences in implementation. When shopping for applications, purchasers should be careful to specify not only the standards they require, but also their interoperability requirements, such as the CA's whose certificates must work with an application.

It is still frustrating to note that there is little ability to share keys between applications and the PKI functionality of the applications themselves are severely limited. Many users find it so difficult as to be nearly impossible to perform simple tasks such as moving a digital certificate and associated key pair from a PC at work to one at home, since today's software often ties the key pair and certificate so tightly to the individual application.

There is a standard which should address this issue going forward—PKCS-12—which provides a way to move certificates, keys and passwords not only between applications, but between systems as well.

Another unfortunate side effect of the hardwiring of PKI functionality is the issue of CA support. Checking in the security options of your browser will reveal a relatively short list of supported Certification Authorities, and adding support for new root keys requires touching every client in the enterprise.

The technical aspects of whether a company hosts its own CA or uses an outsourced service usually concerns operational capacity:

• Does the organization have a 24 x 7 support capability?
  
  
• Does the expertise for security policy creation and management exist in-house?
  
  
• Do internal IT operations have staff who are qualified and capable of running a CA?
  
  
• Are physical security measures sufficient?
  
  
• Can the organization guarantee the security and integrity of its root signing keys?
  
  
• Is the company equipped to handle registration of users to the required standard, particularly when physical registration is demanded by the environment or sensitivity of the applications?
  
  
• Can the company provide an adequate quality of service for the required number of digital ID users?
  
  
• Is the company better equipped, due to strategic advantage or core competence, to provide this service than a CA specializing in outsourcing?

If the answer to any of these questions is no, then the company should carefully weigh the costs of adding the necessary hardware, staff and infrastructure against the costs of outsourcing.

Because of the mission-critical nature of the service associated with a public key infrastructure, the competence of the organization to perform the critical operations correctly should be carefully considered. However, if the organizations's IT unit has successfully demonstrated its ability to operate other vital systems, such as an accounting, billing or corporate messaging systems, then the issues encountered in operating a public key infrastructure in support of inter-organizational business processes should be familiar, and represent no unusual risk.

There are points in favor of an in-house solution, of course, the main one being total control over what is a very sensitive area—there is often a great deal of nervousness displayed when it comes to outsourcing security of any kind. Also, if a public key infrastructure is required only to support confidentiality, integrity and authenticity services for the organizations's own employees, then the considerations are much more relaxed, and there is no reason not to in-source the service.

Bringing the operation in-house will ensure that interoperability problems between CA and corporate applications are eliminated, and the issue of CRL's is greatly simplified. It also ensures that there is never the risk of breaching an outsourcer's Certificate Practices Statement (CPS), either intentionally or otherwise.

Consider the case of a "hybrid" outsourced service where certificates are signed by the company's root signing key, which is turn signed with the outsourcer's root signing key.

What would happen if the outsourcer either intentionally (following a breach of the CPS) or unintentionally revoked the organization's root signing certificate? All the certificates issued by the organization would then be instantly invalidated—and there is no way back following revocation. Once the problem had been resolved, the organization would have to re-issue every single certificate to its users.

While this may not be a big deal in a trial implementation, a year or so down the line in a live banking application it could present a single point of failure for the entire business. Unlikely? Maybe—but would you want to take the risk?

Consequential damage resulting from a failure by the certificate issuing body can far outweigh any direct costs. Therefore, if the certification service is out-sourced, the service provider must be covered by credible insurance for consequential damages, and it must be able to demonstrate that the insurance is continuously in-place.

Simply entering into a contract with a provider which places liability on them is not sufficient, because it does not guarantee their ability to assume that liability for consequential damages in the event of failure. Causing the service provider to go out of business brings no satisfaction when the corporation's critical systems have been compromised.

However, the framework is of little use without applications that take advantage of it. Today's browsers and e-mail packages are beginning to include the ability to sign, verify, encrypt and decrypt data using digital certificates and associated key pairs which are stored in a "secret store" somewhere on the users local hard disk.

In order to support the full key history and automated CRL checking, however, applications need to include much more PKI functionality. This is being implemented via PKI vendor tool kits, and we are beginning to see a new wave of applications which are advertised as "PKI Ready".

Another important question is "how do you find a public key certificate"? Throughout this article we have referred to the requirement to transmit the digital certificate and public key with the message so that the recipient has instant access. Some applications do this automatically—it is a part of the S/MIME standard, for instance. But what happens if you need to communicate securely with someone for whom you have no certificate and who does not know you?

Where one of the well-known public CA's has issued the certificate, life is made easier by the fact that the details are published in a searchable directory. Not every CA is as well known as VeriSign, however, and not all their directories are searchable by just anybody. Ideally, we need one large "master directory" for all certificates issued by any CA, but this Utopia is a long way from fruition.

Only as PKI standards are ratified and compliance becomes widespread will functionality be built into applications. We are in the early stages at the time of writing, and much more work needs to be done to make widespread adoption of PKI a reality.

Bob Walder, a leading authority on network security, is one of the founders of The NSS Group. Since leaving behind the world of IT management in 1991, Bob has been at the cutting edge of new technology and has invested much of his time in advising on, testing and certifying a range of security products on behalf of end user organisations, vendors and certification bodies. He is also a regular contributor of technical articles to the major networking and security titles.

The NSS Group is Europe's foremost independent network and security testing facility. With labs in Cambridge in the UK and Carcasonne in the south of France, The NSS Group offers a range of specialist networking and security services to vendors and end user organisations throughout Europe and the United States. For more information, visit www.nss.co.uk or e-mail info@nss.co.uk.