Using Digital Certificates with Your Application
The choice of digital certificates, or Digital IDs, used in your application matters a great deal. A digital certificate is nothing more than a bag o'bytes. It has no intrinsic meaning. To use a credit card analogy, a digital certificate is the equivalent of a magnetic stripe card. The magnetic stripe card is meaningful only if it can be used for something useful. It's more useful if is says VISA on it than if it says San Jose Public Library or Joe's Office.
Digital IDs generally fall into three classes:
Digital IDs issued by corporate certificate servers
Digital IDs issued by public Certification Authorities (such as Verisign, Thawte, CyberTrust, and so on)
Digital IDs issued by public Authentication Service Providers (such as http://AlphaTrust.com)
Certificates Issued by an Internal Certificate Server
Digital IDs issued by internal corporate certificate servers, such as Microsoft Certificate Server, may be useful for low-value corporate applications. These certificates are normally only valid for use within the corporation that issued the certificates. These digital signatures made using these Digital IDs have no legal meaning, unless the signature is made in a jurisdiction that permits them for the purpose being used. Check with your lawyer. Proper precautions must be taken to securely implement and protect the CA equipment, and policies and procedures must be developed regarding installation, maintenance and administration.
Properly implemented internal CAs can cost between $500,000 and several million dollars to set up, and they can cost at least $60,000 per month to operate (according to Forrester Research). The cost of an internal CA is related to the value of the data or transactions being protected.
Setting up a production enterprise CA involves integrating PKI (Public-Key Infrastructure) software, validation software, directory services, Web applications, and client software. Then you must be prepared to scale these services, because they demand 24×7×365 uptime with rapid, forward-deployed response to validation requests. No wonder the PKI vendors are making their money on consulting services.
Certificates Issued by a Public CA
Public Certification Authorities, such as Verisign, offer Digital ID issuance and management services on an outsourced basis. This is analogous to the enterprise CA discussed in the preceding section, except that you take advantage of the infrastructure already built out by the public CA. Additionally, if you have your Digital IDs issued inside the public network of the CA, they will be recognized by Web-based applications because the root CA certificates for many of these services are built into the browsers. This was done largely to facilitate SSL server validation by Web browsers.
Typically, certificates from public CAs like Verisign are used for public situations, such as on the Internet. When you go to http://Amazon.com to buy a book, you need to be able to confirm that the certificate your browser receives when switching to SSL mode was issued to http://Amazon.com, and not to Joe's Books. By using a certificate issued by a public CA like Verisign, whose root certificate is preinstalled in every Web browser, you can verify the certificate without having to worry about the trustworthiness of the issuing CA.
The downside of this approach is that any Web client will recognize your Digital ID as valid and may rely on signatures made using such Digital IDs. This can lead to large undefined liabilities because you may not have a contract with the other party; they may not be in a jurisdiction that recognizes digital signatures. Also, as a relying party to such Digital IDs, you have no idea how the other party was properly validated, whether they had control of their Digital ID when they made a signature, and what remedies you may have in the event of a breached agreement. In short, legal certainties are low and potential financial liabilities are high.
Most public CAs do not validate the identities of individual users, but rely on delegated enterprise registration agents within companies to validate their own employees. The procedures used to validate users of a public CA's network may, therefore, vary from company to company. Quite often, low cryptographic strength software (to achieve maximum interoperability) is used. The primary use of public CAs has been and continues to be issuing Web server certificates for SSL transactions.
You must also be sure that you have software from the public CA that supports revocation checking and validation checking. Be sure the CA's infrastructure is scaled and responsive to all requests. Many public CAs are essentially outsourced certificate-signing engines and disclaim most all liability for their actions or inaction.
Certificates Issued by a Public Authentication Service Provider
Authentication Service Providers (ASPs) are companies that provide the services of a public CA combined with a complete transaction network that deals with the issues of legalities and risk management. ASPs (such as http://AlphaTrust.com) serve Internet e-commerce application needs where a robust PKI is required, coupled with defined legal validity of transactions and protection against fraud and loss.
ASPs are used by business-to-business e-commerce hubs, commercial Web sites (especially in the financial, medical, legal, and governmental fields), and enterprises to digitally authenticate users into Web resources and provide legally valid digital signatures and encryption for data privacy. ASPs will strongly validate the identity of all users of the ASP's system and stand behind that validation with a strong warranty.
ASPs typically operate a legal framework to which all users are a party and which provides for the legal validity of digital signatures and recourse for all parties—even across international boundaries. The primary business of ASPs is providing a plug-and-play solution for e-commerce applications that strongly authenticates all users and provides a clearly understood and risk-managed environment for e-commerce transactions.
For example, http://AlphaTrust.com, the only commercially operating ASP as of this writing, provides three grades of Digital IDs with $2,500, $25,000 and $250,000 of warranty protection, respectively. It operates a robust PKI with certificate-revocation checking using multiple protocols, and digital signatures made using its Digital IDs have legal validity among all users worldwide.
Certificate Formats
Digital certificates conform to a standard developed by the ITU-T (formerly CCITT), called X.509. It is part of the X.500 directory specifications. X.509 certificates are specified in three versions: v1, v2, and v3. The Internet Engineering Task Force has profiled X.509 certificates for use with Internet applications. This is defined in RFC 2459 (available from http://www.ietf.org). This RFC specifies X.509v3 certificates. V3 certificates contain certificate extensions. Several of these extensions have legal and policy implications. They are designed for automated processing by software, and the software is expected to understand the meaning of these extensions.
Extensions can be marked as critical or not. If an extension is marked critical and the software does not understand the extension, the software must not process or rely on the certificate.
V3 extensions specified in RFC 2459 that can have legal or policy implications include
Key usage
Extended key usage
Certificate policies
Policy mappings
Basic constraints
Name constraints
Policy constraints
You should consult this specification before using certificates including these extensions.
Single-Purpose Versus Multipurpose Certificates
Two primary purposes for which digital certificates are used are digital signatures and encryption (key encipherment). Many implementations in use on the Internet today use a single certificate for all uses (a multipurpose certificate). Such certificates are issued to an individual and used for digital signatures (in client authentication and secure email (S/Mime)) and encryption (secure email and encrypting file system in Windows 2000). Often, the key usage extension is absent or specifies both digital signature and key encipherment.
Attacks are possible when the same certificate is used for both digital signature and encryption applications. A better design is to use a separate certificate for digital signature and another certificate for encryption. This is accomplished by setting the appropriate key-usage extension in each certificate and setting the extension as critical.
An interoperability issue exists with single-purpose certificates. When used in some applications, such as S/MIME email, the client application ignores the key-usage extension and uses the first certificate it finds for the purpose it needs. This can result in a digital signature certificate being used to encrypt information to an email recipient. The recipient will not be able to decrypt the email because it can't use its digital signature certificate for this purpose.
When deciding on single versus multipurpose certificates, you must consider the environment in which certificates will be used.
Trust Models—Choosing the Right One
Public-Key Infrastructures generally come in three flavors:
Open PKI
Closed PKI
Contractual PKI
These infrastructures differ in their scope and availability. Everyone can take part in an Open PKI, while a Closed PKI is limited to those who are part of a specific group or organization. A Contractual PKI is somewhere in between, being closed to all but those who pay for a membership. Which PKI infrastructure is most appropriate depends on the situation.
Issuing Certificates with an Open PKI
Certificates issued in an open PKI (exemplified by Verisign) are designed to be recognized and relied on by all Internet-based applications. This model was developed to support recognition of SSL server certificates. Both Netscape and Microsoft browsers and email applications have embedded within them "root" certificates of many "public" certification authorities.
All certificates issued within these open systems will be automatically trusted by software, whether the user wants to or not. This makes deployment somewhat easier, but it has the effect of exposing the certificate user and certificate issuer to unlimited liability. This is because the certificate user may have no legal relationship (called privity) with the certificate relier that defines the meaning of the transactions. Reliers could rely, to their detriment, on messages digitally signed by the user and have either no recourse or excessive recourse. Also, in some jurisdictions, there is a rebuttable presumption that if a party receives a digitally signed message, the party can rely on the fact that it was signed by the user (whether it was or not). It is then up to the user to prove that the user did not sign something. It is hard to prove a negative. Open PKIs are convenient, but they can be risky. Legal validity, risk management, and transaction privity are usually not defined at all in an open PKI.
Using the Closed PKI
The closed PKI is designed for a closed community of users. This is exemplified by an enterprise PKI, in which all users are members of the enterprise, or by an extranet PKI, such as the Automotive Network Exchange (ANX). In this model, all users and reliers are controlled by an administrative body. Only users who have a specific need are allowed to use the PKI. This model is useful for small communities for which central administration is possible. It is not intended to scale to large numbers.
The Contractual PKI
The contractual PKI offers the best of both worlds. In a contractual PKI, exemplified by http://AlphaTrust.com, participation in the PKI is open to almost everyone; however, each participant must apply for membership in the system. In joining the contractual PKI, the user must agree to the usage or member contract. This has the advantage of bringing all users of the system into contractual privity with one another, thereby defining the rights, responsibilities, and risks of participants.
Contractual PKIs are often operated as part of an Authentication Service that provides other benefits, such as legal validity of digital signatures, warranty protection for transactions, online validation of certificates, and value-added services such as time stamping, audit trail, and archiving. Using certificates provided by an ASP are often an excellent choice for Internet applications.