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 • We can deploying these right now CA repository Clients Bob Alice

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

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. 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 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 • 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