Public Key Infrastructure (PKI)
Workshop
 Summary Observations and Recommendations

 

Prepared for Cornell University
February 15, 2002

 

 

 

Contents

 

Introduction

The Burton Group conducted a Public Key Infrastructure (PKI) Workshop on the Cornell University campus in Ithaca, NY, on January 29 — 30, 2002. Some 20 representatives from several departments, including Computer Science, Computing Director Office, and Undergraduate Admissions, participated in the workshop. The purpose of the workshop was to:

Proceedings

The Workshop consisted of the following events:

 

Observations

During the course of our pre-workshop meeting, workshop presentations, and discussions, we identified the following conditions:

 

Analysis and Recommendations

Public key security holds a great deal of promise for Internet-based applications and services. Public key security provides critical security services, including authentication, integrity, and confidentiality, in highly distributed systems, making it ideal for Internet applications. Therefore, it seems inevitable that some form of public key security will become the preferred security system for important Internet applications. Indeed, public key security has become the foundation for important Internet security standards, including the Transport Layer Security standard (formerly known as SSL) for authenticating Web servers and the Secure Multipurpose Internet Mail Extensions (S/MIME) standard for secure messaging.

It’s important, however, to distinguish between public key security and the public key infrastructure, or PKI, necessary to manage it. PKI adds layers of security to public key systems by supporting X.509 digital certificates and the facilities for managing both encryption keys and certificates. In short, PKI adds many useful features and functions to public key systems. But as is the case with any technology, those features and functions come at the price of additional complexity. Today, then, there many outstanding issues related to PKI.

First and foremost, it’s important to remember that PKI isn’t a complete security solution on its own. PKI will serve the Cornell University best when it’s part of a comprehensive security architecture that includes general-purpose directory and authorization services. In addition, it’s important to understand that PKI isn’t just technology. It involves people, process, policy, and law. The industry has yet to sort out many issues, including complexity, manageability, and legal precedent, so caution is warranted.

For these reasons, we are fond of saying that the "I" in PKI, is only just emerging. The industry has made a great deal of progress in creating PKI standards in the last two years, and vendors are providing increasingly robust products. But many standards are immature, and as is the case in any market, customer needs (and products) are evolving faster than the standards. Today, interoperability, manageability, liability, and policy remain significant issues.

Still there are reasons to deploy PKI and to seriously consider plans for deploying PKI in the future. This is especially true for organizations such as the Cornell University. As we’ve said, public key security is poised to play a strategic role in Internet applications. Consequently, organizations that intend to use the Internet to conduct business must prepare themselves for the inevitable. And organizations that want to shape PKI policy within their community must get involved early in order to influence that community.

Today, there are several standards efforts and community organizations working to address the deployment barriers that prevent wider PKI adoption. The Internet2, Educause, and CREN have collaborated to create the Higher Ed Bridge Certificate Authority, which just completed a successful round of testing with the Federal Bridge Certificate Authority. The Organization for the Advancement of Structured Information Standards (OASIS) has technical committees developing the Security Assertions Markup Language (SAML) and XML Key Management Services (XKMS), which will have potentially significant impact on Cornell University’s plans to deploy PKI. In addition, Internet2 has made great strides with the Shibboleth project and is working closely with the SAML community to bring viable cross-security domain identity sharing to reality. While complexity, interoperability, application integration, and cost issues are barriers to immediate PKI deployment at Cornell, the University and its member institutions must prepare for PKI by first planning and then deploying PKI applications with clear scopes (limitations) and goals (solving a real problem). Simply put, Cornell University should be planning its PKI strategies and policies, viewing those efforts as an essential part of creating e-business infrastructure. Whenever possible, the University should strive to create general-purpose security infrastructure that many applications can leverage, integrating that infrastructure with directory and authorization services.

Only then can Cornell meet its goals of inter-institutional information sharing, cross-institutional curriculum enrollment, and secure electronic grant submissions in a scalable, secure, and manageable form. And by getting actively involved now, Cornell can influence the evolution of PKI policy and law as well as interoperability improvements in the higher education community at large.

During workshop discussions and Cornell presentations, digital signatures were frequently discussed for several applications. It became clear, however, that digital signature requirements varied widely across the applications mentioned. For example, applying digital signatures to grade submissions can be very different from signing grant requests to be submitted to NIH. A key aspect of this problem is the degree to which Cornell will go to validate the identity of individuals that digital certificates are issued to and the assurance level assigned to those certificates.

Validating the identity of digital certificate recipients will be a formidable challenge that will become manageable if Cornell outlines a clear and simple policy outlining certificate assurance levels. Once policy is determined, Cornell can decide what mechanisms and processes to employ to satisfy certificate policy guidelines. To vet active students, faculty, and staff will be much more straightforward than if Cornell desires to issue certificates to applicants or even prospects. Cornell must analyze the objectives of all efforts to issue digital certificates to the various constituencies it deals with to ensure project success.

In addition to the technical level investigation of PKI that Cornell will undertake, Cornell must also prepare for the training and awareness necessary to educate users that will be issued digital certificates. Today, most computer users are not aware of what digital certificates are, how to properly handle or store them, or what to do when something goes wrong. Application developers do not have an abundance of easy to use programming tools to incorporate PKI into applications and systems. Furthermore, system administrators will have new system components to manage and maintain to ensure adequate availability.

To assist Cornell in future PKI planning, Burton Group makes the following recommendations, which we split into three groups: General Recommendations, Recommendations Regarding PKI, and Minor Concerns.

General Recommendations

Burton Group makes the following general recommendations to Cornell University:

Recommendations Regarding PKI

Burton Group makes the following PKI recommendations to Cornell University:

Other Issues

Workshop participants discussed the following topics, agreeing that they are concerns shared by many of the member institutions:

 

Appendix A: PKI Technical Position Outline

 

Appendix B: Acronyms

 

 

Return to PKI page | Authentication home page

Last modified: May 25, 2007

Computing at Cornell Homepage CUinfo CIT Contact List Send Us Feedback