PKI Overview Tim Polk, NIST [e-mail] Background Secre

1
PKI Overview

• Tim Polk, NIST
• wpolk_at_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?
• whos 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 dont 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 its public key
• clients can construct chains of linked bindings

7
Public Key Infrastructure
Carol
CA-1
CA-3
CA-2
Alice
Bob

• 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
  Internet-specific 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
NISTs 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 dont
  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
• weve 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 doesnt have to
  search
• not a complete solution because you cant always
  predict the path for the receiving client

27
The Application Vacuum

• PKI-aware products are limited
• TLS and SSL (browsers), S/MIME
• Why arent 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 InterestGroups 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
• cant support a global infrastructure today
• arent 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_at_nist.gov