This document provides an overview of public key infrastructure (PKI). It discusses how PKI uses public key cryptography and digital certificates to securely distribute public keys. A PKI relies on certificate authorities (CAs) to issue and revoke certificates binding public keys to their owners. It also discusses the roles of CAs, registration authorities, repositories, and clients in a PKI. The document outlines how standards bodies are working to develop PKI standards and the need for testing interoperability between PKI components. It notes that while PKI can support some applications today, a global public key infrastructure is not yet achievable and full interoperability has not been established.

1. PKI Overview
Tim Polk, NIST
wpolk@nist.gov

2. Background
Secret key cryptography works, but key
management is a nightmare
Public key cryptography uses two keys
– one that is secret to the “owner”
– one that is widely available
And all our problems were solved?
– who’s key is this anyway?
– who says so?

3. Public Key Infrastructure
Secure, reliable, and scalable method for
distributing public keys for secrecy,
correctness, and sender verification
“Binds” the owner to the public key using a
digital certificate
Maintains and distributes status information
for the life of that binding

4. Roles of PKI Components
CA is like the DMV and issues and revokes
certificates
RA is the person that checks your identity
Client have and use certificates
Repository stores the certificate and status
information so clients don’t have to

5. A Basic PKI
CA
repository
Clients
Bob
Alice
We can deploying these right now

6. Growing A PKI
bigger PKIs can be constructed by
connecting CAs
they issue certificates to remote CAs,
binding the remote CA to it’s public key
clients can construct “chains” of linked
bindings

7. Public Key Infrastructure
repository
Carol
CA-1
repository
CA-2
Bob
CA-3
Alice
A “real” PKI has multiple CAs with clients
CAs and repositories are the basic building
block

8. PKIs are simple...
as long as you have just one CA and one
repository
– theoretically, they are like lego blocks
– in practice, they can be like a box of bicycle
parts on Christmas Eve
the complexity is the result of
– unstable standards
– non-interoperable products and applications

9. Standardization Activities
IETF (PKIX WG)
ISO JTC1/SC6 directory work
ANSI X9F and ISO TC68/SC 2/WG 8

10. IETF Public Key Infrastructure
Using X.509 (PKIX) WG
Formed in 1995
Five RFCs issued in ‘99, four more
approved in the last month
–
–
–
–
certificate and CRL formats
PKI transaction formats and protocols
Certificate Policy Statements
certificate and certificate status retrieval
mechanisms

11. Certificate and CRL Formats
Base profile is complete (RFC 2459)
– based on X.509, but adds semantics to Internetspecific fields and data
Supporting documents are (nearly)
complete
– KEA (RFC 2527) and ECDSA (I-D)
– enhanced CRLs (I-D)
– enhanced name semantics (I-D)

12. Transaction Formats and
Protocols
Three major specifications
– Certificate Request Message Format, or CRMF
(RFC 2511)
– Certificate Management Protocol, or CMP
(RFC 2510) [references 2511]
– Certificate Management Messages over CMS,
or CMC (I-D) [references 2511]
Is there room for CMP and CMC?

13. Certificate and Certificate Status
Retrieval
A wealth of choices
–
–
–
–
LDAP V2 schema
LDAP V2 profile
FTP and HTTP
OCSP

14. New PKIX Work
Timestamp service protocol
Data certification service protocol
Attribute certificates

15. ISO Directory Work
Three projects in the directory area were
assigned to JTC1/SC6
– X.509
» maintaining the public key certificate work
» new work in attribute certificates
– X.500 directory work
– ASN.1 (X.680?)

16. ANSI X9F
Provider of cryptographic standards
Developing certificate and certificate
extension profiles for banking community
– TC68 documents 15782-1 and 15782-3
Defining short certificates for bandwidth or
storage impaired environments
– smart cards, cell phones, etc.
Attribute certificate work (15782-2)

17. Standardization Summary
ISO, IETF and ANSI are making good
progress
Most of the work is complementary, or at
least well-aligned
There are still too many choices in some
areas (transaction and retrieval protocols)
Parallel attribute certificate projects may
result in divergent standards

18. Interoperability Testing
The new frontier
– PKI interoperability
– PKI component interoperability
Issues:
– are certificates and CRLs well-formed?
– can components request/revoke certificates?
– can clients build/validate paths?

19. NIST’s PKI Interoperability
Testbed
Project Goals:
– Creation of complex directory systems
– Creation of heterogeneous PKIs
– Determination of client functionality
Summary:
– the state of the art is a homogeneous PKI with
a very small number of CAs and exactly one
directory

20. PKI Component Interoperability
Testing
Three basic components
– CAs: X.509 certificate and CRL generation
– Clients: X.509 path validation
– CAs, RAs, clients: transaction message formats
and protocols
As protocols stabilize, interoperability
testing is the logical next step

21. Tools for Interoperability Testing
reference implementations
– MISPC Reference Implementation from NIST
(X.509, CMP, and CRMF)
– IBM (X.509, CMP, and CRMF)
Conformance tests
– NIST (CMP, CRMF)

22. PKI deployment
Many pilots ongoing or planned
– “many will play, few will win!”
Why?
– directory infrastructure
– application vacuum
– unreasonable expectations

23. Directories
Often the problem, instead of the solution!
– X.500 directories
– LDAP directories
Alternative solutions
– alternative retrieval protocols
– all-inclusive packaging

24. X.500
the global X.500 directory is a myth
– it would resolve most access problems
– it would introduce new problems
» DIT management
– shadowing, replication and chaining
» well specified
» not well tested (different implementations don’t
actually interoperate!)

25. LDAP
LDAP is ubiquitous, but:
– resolves localized access problems
– relies on referrals to scale
» performance bottleneck
» poor client support
– shadowing, replication and chaining
» proprietary solutions, if they exist at all
» may be addressed in LDAP V3 extensions

26. Alternative Solutions
Why rely on directories at all?
– FTP/HTTP/DNS retrieval
» we’ve already got these servers, and they work!
» requires a pointer in the certificate
– all-inclusive packaging (S/MIME)
» just include the certificate(s) and CRL(s) in each
transaction and the client doesn’t have to search
» not a complete solution because you can’t always
predict the path for the receiving client

27. The Application Vacuum
PKI-aware products are limited
– TLS and SSL (browsers), S/MIME
Why aren’t there more PKI-aware
products?
– chicken and egg problem (what PKI?)
– not a straightforward upgrade (e.g., adding
digital signatures to insecure applications)
– no standard API (rewrite for every product)

28. Unreasonable Expectations
PKI is a not going to solve all your
problems
– first and foremost, PKI is a key management
solution
– overloading with additional semantics (e.g.,
roles and complex policies) is beyond the state
of the art

29. Piloting for Success
choose an existing application with:
– a close-knit community of users
– security in place (esp. access control), but
– a known key management problem
use a single repository for all information
focus on the key management problem first
attempt to leverage certificates for access
control second (if at all)

30. Current Market Players
PKI product providers
– rudimentary assurance
– high assurance
Service providers
– certificate issuers
– status information providers
Community of Interest Groups
– ANX, Federal Government, financial

31. Community of Interest
Groups Rule
they determine the winners and losers
– communities of interest that use the PKI will
determine the features and protocols
– if no communities emerge to use PKI, it will all
disappear
they are emerging (ANX, US government,
SET, etc.) and PKI will appear in more
applications

32. Summary
The standards bodies have gotten their act
together, but a few thorns remain
The state of the art PKI products
– can support focused applications today
– can’t support a global infrastructure today
– aren’t interoperable, but will be “soon”
Application and directory solutions are
lagging, but vendors will respond to
communities of interest deploying PKIs

33. For More Information
http://csrc.nist.gov/pki
wpolk@nist.gov