Confused about PKI? Don't Worry, IT Leaders Might Be Confused Too

A recent EDUCAUSE Center for Analysis and Research (ECAR) report identified public key infrastructure (PKI) as one of the least familiar technologies in the higher education IT environment.¹ Out of the 83 technologies surveyed for the report, it ranked among the 10 "least familiar" technologies to survey respondents. While we have worked on a secondary ECAR publication to provide a basic definition of what PKI is and why it's important in higher education,² the purpose of this blog is to explore why so many IT leaders might find PKI a confusing technology.

In the ECAR report, 16% of survey respondents said they were unfamiliar with PKI, and 38% of respondents said they had no deployment of PKI. Yet other research shows that certificate use has exploded over the past decade.³ So why are so many institutional leaders responding that they are not involved in or operating a PKI? We believe that most institutions probably are operating a functioning PKI, and that there are several misperceptions about PKI that lead to this technology being among the  least familiar.

Points of Confusion

Confusion is often rooted in misunderstanding. There are a number of points of potential confusion in understanding PKI and PKI implementations:

• The definition of PKI
• The role of a certificate authority
• Complexity in the technology, support, and management of certificates
• Scope and scale of deployments

The Definition of PKI

The first point of confusion we will address is the definition of PKI. PKI supports secure data exchange and authentication over the Internet via the distribution and identification of public encryption keys. PKI generally includes "hardware, software, policies and standards to manage the creation, administration, distribution and revocation of keys and digital certificates."⁴

While generating or having a certificate does not constitute a PKI, some level of PKI must exist to produce the certificate, even if it is just software. Arguably, having and using the software required to generate certificates does not a PKI make. We would agree to the extent that the software is but a portion of the "I" (infrastructure) required to operate a well-managed PKI. The provider manages the infrastructure, life cycle, and distribution of certificates that is a large portion of the "I" in PKI. Just as with many cloud services, an external PKI service operates under a shared security model. Some of the security and management responsibility falls to both the vendor and the consumer. Without judgment or bias as to how thorough or appropriate the operation of the shared responsibility is on the consumer or vendor side, it is still by definition a PKI.

The Role of a Certificate Authority

Another area of confusion is the "P" (public) in PKI as it relates to both public and private certificate authorities. A public certificate authority operates under a common set of standards regarding how certificates are managed and distributed. Audits are performed to ensure that the standards are met. A private certificate authority is not bound by the same restrictions as those of their more diligently managed public counterparts. Which is "better" depends on your needs, and there are good reasons for both. In the end, it really does not matter which is chosen or if both are utilized. When considering the "P" to stand for either public or private, there is no net effect on the "I," and we are back to having a deployed PKI. If you are outsourcing your certificate management to someone like InCommon Certificate Service, then the "P" represents a public key infrastructure. Perhaps the question in future ECAR surveys should be phrased to include both public and private key deployments under the PKI umbrella.

Complex Technology

Confusion surrounding PKI technology is abundant. The asymmetric cryptography that makes use of simple and elegant mathematics at PKI's core has stood the test of time. While the mathematics are simple, the use and management of certificates has proven to be complex enough to bewilder most users and a good number of IT techs. Challenging items include key rotations; certificate authority chaining; appropriately configured use categories; subject alternative names and expiration dates in the certificates themselves; and certificate revocation lists, certificate signing requests, and Online Certificate Status Protocol services external to the certificates that make up part of the "I." These technical challenges and support difficulties may contribute to institutions being unwilling to admit to deploying or operating a PKI if the technology is not understood or managed sufficiently. Suitable training programs for certificate and PKI management that are focused on vendor solutions, security, or certificate management could be made available to staff to address technical shortfalls. The definition of a PKI does not identify any measure of support; it only infers that support exists without addressing depth or breadth.

Scope and Scale

The final point relates to scope in the deployment of certificates, which concerns the point above. It doesn't matter at what scope and scale the certificate services are operated, from the perspective of defining a deployed PKI. The definition does not mention scope or scale; it simply refers to an infrastructure (compared to web services where if only one website exists, it is still a web service). If there are only SSL certificates for servers issued or if the scale needs to support users for 802.1X network authentication or SMIME, there must be an "I" to support it. But scale is not a factor by definition, and a PKI deployment exists regardless of the number certificates issued.

Future Clarity

The 2016 Strategic Technologies report estimates that PKI will be an "emerging" technology by 2021.⁵ We think that may be an underestimate, given potential confusion about the technology. We used basic terminology here to resolve the confounding responses to the PKI survey.⁶ For the 2017 report, we hope to see the results cut through all of the confusion to align with the data.

Notes

1. Susan Grajek, Higher Education's Top 10 Strategic Technologies for 2016, ECAR report (Louisville, CO: ECAR, January 2016).
2. Barry Ribbeck, Paul Caskey, and Ann West, Technology Spotlight: PKI, ECAR research bulletin (Louisville, CO: ECAR, forthcoming); available to ECAR subscribers from the ECAR website.
3. Zakir Durumeric, James Kasten, Michael Bailey, and J. Alex Halderman, Analysis of the HTTPS Certificate Ecosystem, University of Michigan, 2013.
4. "PKI (public key infrastructure)," TechTarget.
5. Grajek, Higher Educations's Top 10, 42.
6. It is curious that we in higher education state that PKI is an emerging technology when it is has been around so long and is so prolific in our federal government [https://www.idmanagement.gov/IDM/s/article_detail?link=entities_cross_certified] in terms of user credentials. Although the federal government may be slow to adopt some technologies, higher education is almost a decade behind in this technology. See the history of the Common Access Card (CAC), which launched in 2006.

Paul Caskey is the program manager, community trust, at Internet2.

Barry Ribbeck is the security program manager at Rice University.

Ann West is the associate vice president, trust and identity, at Internet2.