PKI 101

1. PKI 101 Ken Klingenstein Project Director, Internet2 Middleware Initiative Chief Technologist, University of Colorado at Boulder David Wasley Technology Guru University of California

2. Agenda • Fundamentals - Components and Contexts • The missing pieces - in the technology and in the community • Current Activities - Feds, CHIME, ANX, overseas, PKI Forum, etc. • Higher Ed Activities (CREN, HEPKI-TAG, HEPKI-PAG, Net@edu, PKI Labs)

3. PKI: A few observations • Think of it as wall jack connectivity, except it’s connectivity for individuals, not for machines, and there’s no wall or jack…But it is that ubiquitous and important • Does it need to be a single infrastructure? What are the costs of multiple solutions? Subnets and ITPs... • Options breed complexity; managing complexity is essential

4. A few more... • IP connectivity was a field of dreams. We built it and then the applications came. Unfortunately, here the applications have arrived before the infrastructure, making its development much harder. • No one seems to be working on the solutions for the agora.

5. Uses for PKI and Certificates • authentication and pseudo-authentication • signing docs • encrypting docs and mail • non-repudiation • secure channels across a network • authorization and attributes • and more...

6. A matrix to structure the issues • Rows: PKI Components - hardware, software, processes, policies • Columns: Contexts for usage - community of interests • Cells: Implementation options (in-source, out-source, roll-your-own, etc.) • Note changes over time...

7. PKI Components • X.509 v3 certs - profiles and uses • Validation - Certificate Revocation Lists, OCSP, path construction • Cert management - generating certs, using keys, archiving and escrow, mobility, etc. • Directories - to store certs, and public keys and maybe private keys • Trust models and I/A • Cert-enabled apps

8. PKI Contexts for Usage • Intracampus • Within the Higher Ed community of interest • In the Broader World

9. PKI Implementation Options • In-source - with public domain or campus unique • In-source - with commercial product • Bring-in-source - with commercial services • Out-source - a spectrum of services and issues • what you do depends on when you do it...

10. Cert-enabled applications • Browsers • Authentication • S/MIME email • IPsec and VPN • Globus • Secure multicast

11. X.509 certs • purpose - bind a public key to a subject • standard fields • extended fields • profiles to capture prototypes • client and server issues • v2 for those who started too early, v3 for current work, v4 being finalized to address some additional cert formats (attributes, etc.)

12. Standard fields in certs • cert serial number • the subject, as x.500 DN or … • the subject’s public key • the validity field • the issuer, as id and common name • signing algorithm • signature info for the cert, in the issuer’s private key

13. Extension fields • Examples - auth/subject subcodes, key usage, LDAP URL, CRL distribution points, etc. • Key usage is very important - for digsig, non-rep, key or data encipherment, etc. • Certain extensions can be marked critical - if an app can’t understand it, then don’t use the cert • Requires profiles to document, and great care...

14. Certificate Profiles • per field description of certificate contents - both standard and extension fields, including criticality flags • syntax of values permitted per field • semantics specified • spreadsheet format by R. Moskowitz, XML and ASN.1 alternatives for machine use • centralized repository for higher ed at http://www.educause.edu/hepki

15. Early Profile Commonalities and Differences • Commonalities - • Signing algs either RSA with MD5 or RSA with SHA-1 • Keep the contents simple and generally non-volatile; no-one is doing CRLs yet • Inclusion of some domain component information within the payload • Differences - • Where to put domain information (altsubjname,subjname,issuername, etc) • What fields to mark critical • How to use constraints

16. OIDs • numeric coding to uniquely define many middleware elements, such as directory attributes and certificate policies. • Numbering is only for identification (are two oids equal? If so, the associated objects are the same); no ordering, search, hierarchy, etc. • Distributed management; each campus typically obtains an “arc”, e.g. 1.3.4.1.16.602.1, and then creates oids by extending the arc, e.g 1.3.4.1.16.602.1.0, 1.3.4.1.16.602.1.1, 1.3.4.1.16.602.1.1.1)

17. Getting an OID • apply at IANA at http://www.iana.org/cgi-bin/enterprise.pl • apply at ANSI at http://web.ansi.org/public/services/reg_org.html • more info at http://middleware.internet2.edu/a-brief-guide-to-OIDs.doc

18. Cert Management • Certificate Management Protocol - for the creation, revocation and management of certs • Revocation Options - CRL, OCSP • Storage - where (device, directory, private cache, etc.) and how - format (DER,BER, etc.) • Escrow and archive - when, how, and what else needs to be kept • Cert Authority Software or outsource options • Authority and policies

19. Certificate Management Systems • Homebrews • Open Source - OpenSSL, OpenCA, Oscar • Third party - Baltimore, Entrust, etc. • OS-integrated - W2K, Sun/Netscape, etc.

20. Public Domain Alternatives • Mozilla • SSLEAY (Open SSL) (www.openssl.org) • Open CA (http://www.openca.org/docs/mission.shtml) • vandyke and Cygnacom libraries in the public domain for path math

21. Directories • to store certs • to store CRL • to store private keys, for the time being • to store attributes • implement with border directories, or ACLs within the enterprise directory, or proprietary directories

22. Certificate Policies Address (CP) • Legal responsibilities and liabilities (indemnification issues) • Operations of Certificate Management systems • Best practices for core middleware • Assurance levels - varies according to I/A processes and other operational factors

23. Certificate Practice Statements (CPS) • Site specific details of operational compliance with a Cert Policy • A single practice statement can support several policies (CHIME) • A Policy Management Authority (PMA) determines if a CPS is adequate for a given CP.

24. Inter-organizational trust model components • Certificate Policy- uses of particular certs, assurance levels for I/A, audit and archival requirements • Certificate Practices Statement- the nitty gritty operational issues • Hierarchies vs Bridges • a philosopy and an implementation issue • the concerns are transitivity and delegation • hierarchies assert a common trust model • bridges pairwise agree on trust models and policy mappings

25. Trust Chains • verifying sender-receiver assurance by finding a common trusted entity • must traverse perhaps branching paths to establish trust paths • must then use CRLs etc. to validate assurance • if policies are in cert payloads, then validation can be quite complex • delegation makes things even harder

26. Trust chains • Path construction • to determine a path from the issuing CA to a trusted CA • heuristics to handle branching that occurs at bridges • Path validation • uses the path to determine if trust is appropriate • should address revocation, key usage, basic constraints, policy mappings, etc.

27. Trust chains • When and where to construct and validate • off-line - on a server - at the discretion of the application • depth of chain • some revocations better than others - major (disaffiliation, key compromise, etc.) and minor (name change, attribute change) • sometimes the CRL can’t be found or hasn’t been updated

28. Mobility Options • smart cards • USB dongles • passwords to download from a store or directory • proprietary roaming schemes abound - Netscape, VeriSign, etc. • SACRED within IETF recently formed for standards • Difficulty in integration of certificates from multiple stores (hard drive, directory, hardware token, etc.)

29. All the stuff we don’t know… • Revocation approaches • Policy languages • Mobility • Path construction in complex trusts • Operating system and token security issues • User interface

30. Internet2 PKI Labs • At Dartmouth and Wisconsin in computer science departments and IT organizations • Doing the deep research - two to five years out • Policy languages, path construction, attribute certificates, etc. • National Advisory Board of leading academic and corporate PKI experts provides direction • Catalyzed by startup funding from ATT

31. Activities in other Communities • PKIX (http://www.ietf.org/html.charters/pkix-charter.html) • Federal PKI work (http://csrc.nist.gov/pki/twg/) • State Govts (http://www.ec3.org/) • Medical community (Tunitas, CHIME, HIPAA) • Automobile community (ANX) • Overseas • Euro government - qualifying certs • EuroPKI for Higher Ed (http://www.europki.org/ca/root/cps/en_index.html)

32. Ah, the public sector… • almost universal community of interests • cross-agency relationships • complex privacy and security issues • limited budgets and implementation options • sometimes ahead of the crowd and the obligation to build a marketplace

33. Activities in Higher Ed community • Federal - ACES, etc. • State Governments - Washington, Virginia, Texas, etc. • HEPKI • the Grid

34. HEPKI • HEPKI - Technical Activities Group (TAG) • universities actively working technical issues • topics include Kerberos-PKI integration, public domain CA, profiles • will sponsor regular conf calls, email archives • HEPKI - Policy Activities Group (PAG) • universities actively deploying PKI • topics include certificate policies, RFP sharing, interactions with state governments • will sponsor regular conf calls, email archives

35. Key issues • trust relationships among autonomous organizations • interoperability of profiles and policies • interactions with J.Q. Public • international governance issues

36. Will it fly? • Well, it has to… • Scalability • Performance • OBE • “With enough thrust, anything can fly”

37. Where to watch • middleware.internet2.edu • www.educause.edu/hepki • www.cren.org • www.pkiforum.org