Practical PKI
by Robert E. Booker, Control Data Systems, Inc.
(Originally published in Messaging Magazine, September/October 1999)

It is another crisp autumn day. The sun is shining, the birds are singing, and you have just had an interesting 3-hour meeting with the helpful sales team from PKI-4-Ever. You feel empowered because you now understand the registration model, standards, application support, private key recovery capability, certificate validation, root key protection, and directory integration used in the PKI-4-Ever solution. You are ready to catalog, compare, and contrast their solution with the presentations, white papers, and proposals you’ve received in meetings with three other solution providers. You may finally have found the solution you need to fulfill your company’s needs.

Life is wonderful! You’ve been tasked to evaluate, select, and deploy the Public Key Infrastructure (PKI) for your company—a progressive organization in a major industry sector with bold plans to enter electronic commerce in a big way. Your meetings with solution providers have convinced you that PKI is the critical component of the e-commerce framework. You are happy to be working with cutting edge technology in support of a major initiative. You enjoy the discussion of private keys, public keys, certificate policies, and the critical roles these technologies play in the successful deployment of an infrastructure.

Your handheld organizer announces your last meeting for the day. You have a briefing with the CIO and her staff to discuss the budget forecast and implementation schedule for the PKI portion of the project. You confidently walk to the meeting, ready to educate another member of the management team with your thorough knowledge of cryptography, public key certificates, legal issues, and operational considerations. You enter the meeting to find a stern-faced executive leafing through your detailed, 42-page project brief. The meeting is short and to-the-point. You furiously scribble notes, but the salient points will always ring in your ears. "…Your 2-year schedule for deploying the PKI is unacceptable…The electronic commerce program is at risk of failure…The business units will never accept the capital cost…" You leave with an action item to rework the brief that you painstakingly crafted over the past 6 months. You will deliver a more acceptable approach, investment model, and project plan for review and approval in a meeting 1 week from today. After all, the Board and market analysts are interested in this initiative, and "time is money."

You call home to tell your family that you’re going to be late tonight. You look at the carefully constructed architecture on your whiteboard and think to yourself, "How can I educate my management that a solid PKI can’t be built from the ground up in 6 months?"

You turn away and look out the window, deep in thought. It suddenly occurs to you that the birds are not singing anymore.

Many organizations are piloting and deploying PKI solutions as a critical component of their e-commerce frameworks. The industry survey question has changed from "Will you implement a PKI?" to "When will you implement your PKI?" The complexity of these highly integrated solutions is well-known, and implementation decisions have a ripple effect throughout an organization’s technology, application, and operations environments. However, decision-makers and program teams need to separate PKI fact from fiction. The true complexity of these programs is only proportionate to application needs and information sensitivity. Technology providers are focused on winning the hearts and minds of each customer, in order to establish market leadership for their companies. Customers focus on making prudent buying decisions and major capital investments—today, with the promise of realizing significant benefits tomorrow. They question if it is prudent to make buying decisions and investments today, when the technologies, and the industry, are churning rapidly to meet tomorrow’s requirements. It is possible, and usually appropriate, to make practical decisions in our PKI programs. Practical PKI programs are much more than technology decisions. Such programs reuse existing information about individuals, their roles, and their affiliations. Practical PKI programs are built in conjunction with existing human resources systems, as well as a variety of customer and partner systems. Practical PKI programs also use existing organizational policies and practices for registration and revocation. In addition, practical PKI programs focus on deployment for business and application needs, rather than technological elegance.

Successful achievement of these objectives, however, requires careful consideration of four important questions regarding application fit, community, management and administration, and build-or-buy decisions.

Application Fit Practical PKI question #1: What applications does the organization require that rely on a public key infrastructure? In the past 4 years, the PKI application scope has evolved from an interesting technology that facilitates data encryption and digital signatures. Today’s PKI application scope supports more compelling organization needs, such as secure e-mail, Web authorization and encryption, virtual private networks (VPNs), and non-repudiation of transactions. Some solutions today are positioned to support the Web and e-mail world, while other solutions are more focused on application authorization and the utopia of single sign-on. Today’s PKI technology also yields several benefits for transaction-oriented applications, including: privacy through data encryption, transaction assurance through digital signatures, authorization through the use of digital certificates as credentials, and personalization of service. Table 1 relates these benefits to the various PKI applications, and identify the most pressing considerations that contribute to the complexity of the solutions.

Today, organizations can deploy a PKI that issues certificates to support all of these application environments. However, organizations frequently do not require all of these capabilities in their first wave of PKI deployment. The technology continues to evolve rapidly, and architectural planning for requirements that will surface in 2 years remains difficult and still impacts the delivery of today’s solutions. Practical PKI programs may require deployment of a limited infrastructure to support the most critical and compelling programs. A practical approach is to start small, with limited scope, and grow the solution as new requirements and capabilities emerge.

Community

Practical PKI question #2: What community must I be able to identify and support through the use of digital certificates?

In addition to a variety of technical factors, the complexity associated with PKI deployment encompasses such considerations as:

• management and administration of the community of subscribers to the service,
• support of required desktop software components and revision levels,
• implementation of sound policies and practices to protect the organization’s interests, and
• integration with the application environments.

Each of these considerations increases dramatically as the community size and complexity increases. It is therefore practical to focus initial deployments on specific communities, rather than all of the communities that are candidates for support by the service.

The scope of the community supported by a PKI is also critical to the technology and vendor selection decisions, as well as the overall capital cost and operational cost of the solution. In particular, an organization should consider the following three community-related perspectives:

• Open or Closed—In an open community, the identity of an individual is not based on an existing business relationship, as it is in a closed community. Internet portals are an example of an open community application, while online banking applications typify a closed community. The bank must know whom they are dealing with regardless of the use of a digital certificate.
• Internal or External—Internal communities consist of employees and application entities within the organization. By contrast, external communities typically consist of trading partners or customers outside of the organization.
• Role and Affiliation—The role and affiliation of an individual are often as important as the individual’s identity. This is especially true in dealing with business-to-business relationships, in which an individual acts on behalf of a business with which a trading relationship exists.

Deployment of early PKI applications is easier to achieve in closed communities where an existing relationship already exists. Internal communities are also easier to deploy and manage. However, external communities provide a greater business benefit and a more compelling business case.

Management and Administration

Practical PKI question #3: How do I manage and administer the community and the certificates issued to its individual members?

As a practical matter, business priorities and e-commerce dictate the appropriate type of community for initial deployment of a PKI and associated applications. Part of this decision process involves considering the management and administration processes required for PKI. These processes address several required elements that must be considered for PKI solutions both big and small:

• Registration and Verification—Organizations may choose from a variety of existing registration models through which individuals or communities may be registered to the PKI service. For example, self-registration may allow a subscriber to complete their own registration application, or it may be based on back-office registration practices. Registration requests must be verified to the level of integrity required by the service. In some cases, the organization may require that an individual validate the application to ensure that it conforms to organizational policy. In other cases, an automated process or existing credentials may be used to validate the application by verifying the individual against existing data services.
• Revocation—Revocation is often the forgotten consideration in initial PKI deployments. The use of existing termination processes for employees, customers, and trading partners is more practical than manual revocation processes in which a registration authority must revoke the certificate associated with an individual.

As a practical matter, the use of existing registration and validation processes to identify a closed subscriber community will greatly reduce the complexity of the PKI deployment, and will further leverage existing administrative practices. Human resources, customer, and trading partner databases are all excellent candidates as data sources for a PKI deployment because employees are almost always paid on time, while customers and trading partners are invoiced and have receivables and/or payables.

The use of existing organizational data and practices in the PKI registration process offers the benefit of associating an individual’s certificate with information that may already be known about the individual. Thus, the information about an individual can include attributes and elements that provide a richer application experience. For example, the individual’s e-mail address may reside in a directory service and may be able to be provided to the certificate registration process through an automated process.

A major issue in deploying a PKI is the analysis invested in determining the level of assurance required for identity validation. PKI deployments are often viewed as requiring the level of trust associated with cash management systems and trading systems. This may be appropriate in some cases, but digital certificates can often be used for lower-assurance applications such as secure e-mail or Web authentication. In these cases, digital certificates provide a better level of assurance than user IDs and passwords, provide for a better user experience, and are superior to the existing infrastructure. Therefore, for applications with low assurance requirements, it may be more practical to consider a best-effort approach to identity validation, and reserve the analysis and complexity of highly trusted certificates to applications that require non-repudiation.

Build or Buy

Practical PKI question #4: Should I operate my own PKI, or is it better to rely on a managed services provider with expertise in this area?

Early in the project cycle, an organization must decide whether to deploy and operate the PKI internally (in-source), rely on a service from a trusted third-party (out-source), or manage the registration process internally and interoperate with a service provider who provides the certificate authority (co-source). The decision involves far more than the cost of ownership/capitalization. The application requirements, the community, and the management and administration requirements all affect this decision.

Different solution providers have different approaches. How to operate the service is a critical decision that requires careful consideration. A "one size" PKI does not fit all application and community needs.

For a closed community, an organization would use essentially the same management and administration model whether the technology is deployed internally or purchased as a service. The organization is always responsible for registration, verification, and revocation of users, as well as publication of certificates to directory services and application repositories. Management and administration affect the cost-of-ownership much more than the capital cost of the software and hardware or the recurring service fees.

In-source solutions are required when the registration and certification processes must be managed internally for statutory or political purposes.

As a practical matter, organizations will end up with multiple PKI solutions in the future. Trusted third parties may be used for lower-assurance applications, such as secure e-mail and consumer Web access while more highly trusted internal services may be used for application authentication, business-to-business communications, and transaction support. Investment in enterprise-wide licensing of specific technologies should be carefully weighed to ensure that the investment in today’s technologies has value for tomorrow’s business requirements.

Summary

Much of the complexity associated with deploying a PKI cannot be eliminated. However, practical decisions regarding the early applications, communities, management and administrative practices, and deployment model are critical to early success or frustration. A steady program with milestones that enable early project success is more practical than enterprise-wide deployment plans that impact multiple business units. A gradual and careful investment in specific technologies and service solutions is prudent, given the rate of change in the industry.

Practical PKI is possible! Careful planning, reasonable expectations, and good communication both internally and with your customers, trading partners, and technology providers will ensure that the birds keep singing from project launch to completion.   MM

For information on article reprints, contact Jay Devine, Communications Manager at jay.devine@ema.org.

Back to Table of Contents