PKI 150: PKI Parts Policy & Progress

1. PKI 150:PKI Parts Policy & Progress Jim Jokl. University of Virginia David Wasley University of California

2. Agenda • Part 1: Fundamentals • Components and Contexts • Policy and Trust • Missing pieces - in the technology and in the community • Part 2: Current Activities - filling in the missing pieces • Federal PKI activities • HIPAA related PKI activities • Higher Ed Activities (CREN, HEPKI-TAG, HEPKI-PAG, Net@edu, PKI Labs) • Certificate profiles • Mobility • Interoperability • and more . . .

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.” - Ken Klingenstein • Options breed complexity; managing complexity is essential;The hard part is making it seem simple to the users. • We’ve always known we needed strong authentication and data security but it is hard so we put it off. Unfortunately, now the applications have arrived before the infrastructure, making its development much harder.

4. What is PKI? • Public Key Infrastructure (PKI) is a system to generate and use asymmetric cryptography to secure and validate digital documents. • asymmetric cryptography uses a pair of large prime numbers such that whatever one encrypts, only the other can decrypt • data security is achieved by encrypting a document using a “public key” so that only the holder of the other (“private”) key can decrypt it • a digital signature is achieved by encrypting a document with a “private key” • validation of the signature is done using the corresponding “public key” • A digital credential is formed and signed by a trusted authority • x.509v3 is the current format for digital credentials • the contents of the certificate relate in some way to the holder/“Subject” • it includes a “public key” generated by the holder/“Subject” • See for example “Digital Certificates and Public Key Infrastructure”http://www.iplanet.com/products/iplanet_certificate/whitepaper_2_1_1_3ad.html

5. Why PKI? • Authentication and pseudo-authentication • What is “identity” anyway?? • Digital signing of important documents, e.g. contracts, memos, etc. • Encrypting documents, e.g. email • Validation of digital signatures (non-repudiation) • Secure communication across a network • Authorization rules require trusted attributes re: Users • Resources are increasingly located off campus • Reliable inter-institutional trust is essential • and more...

6. PKI Contexts for Usage • Intracampus • appropriate access management for institutional resources • scalable distributed authority and responsibility • auditable paperless transactions • data security • verifiable web documents • reliable digital archiving • Within the Higher Ed community of interest • sharing of resources among campuses, classes • working group management • In the Broader World • e-commerce partners • Federal agencies • Etc., etc., etc.

7. Some Cert-enabled applications • Browsers • SSL negotiation • User authentication • Server Authentication • Cert must be issued by trusted authority • S/MIME email • IETF IPsec and VPN • Globus • Secure multicast • Future - access to QoS transport, etc. • A goal of Middleware is to allow easy conversion of other apps.

8. PKI Components • X.509 v3 certificate definitions • Certificate Policy and Certification Practices statements (trust) • Cert management - generating key pairs, issuing certs, archiving and escrow, mobility, etc. • Directories - to store certs and public keys, Subject attributes, and maybe private keys • Trust path construction & validation • Certificate Revocation Lists, OCSP • Cert-enabled applications

9. X.509 v3 Certificates • Purpose - to bind a public key to a Subject • Subject is “identified” by fields in the cert (may be a “group”) • Other information may be retrieved using these fields • Standard fields • Extension fields • client and server issues • v3 for current work • v4 being finalized to address some additional cert formats (attributes, etc.) • No meaning should be attached to anything in the cert except as defined in the Certificate Policy and Certification Practices statements • e.g. a Subject may not be assumed a member of MIT merely because they have a cert issued by MIT - unless the CP/CPS says that is true.

10. Subjects and Identity • Identity is the set of attributes that pertain to an entity; the particular attributes that are important depend on context. • Some attributes are shared: • gender, name (often), affiliation (student, faculty, staff), etc. • Others are specific to the entity: • Dean of Physics, employee ID (hopefully!), SSN (well...), DL# (?), etc. • email address should be pretty good • example of a qualified identifier • The “value” of some attributes changes over time • credentials should contain long-lived attributes to minimize revocation • What a target application or server needs to know may not be in the credential - • therefore additional attributes need to be available in directories

11. Certificate Types • Certificates can assert many different types of things • their useful meaning will depend on applications understanding them • Identity Cert - contains something useful about the holder • Pseudonymous Cert - contains only a unique “handle” for the holder • Anonymous Cert - contains only attributes shared by a defined group • e.g. “faculty” or “member of the campus community” • Encryption Cert - used for securing data • may require escrow of the private key - therefore unsuitable for signing • Signature Cert - may be needed to hold additional attributes such as role or authority • Cert is archived for as long as the signature must be validatable • Function Cert - asserts eligibility without revealing specific identity • e.g. electronic voting

12. Standard Fields in Certs • Cert unique serial number • The Issuer, as x.500 DN • must be identical to the Subject field in the Issuer’s authority cert • The Subject, as x.500 DN • The Subject’s public key • The validity period • The signing algorithm • The signature info for the cert, created with the issuer’s private key • See IETF RFC 2459 for all the gory details

13. Extension Fields • “Standard” and “private” • Standard extensions include • issuer/subject altnames, key usage, CRL distribution points, policy and practices pointers, etc. • Key Usage is very important - for digital signature, non-repudiation, key or data encipherment, etc. • Private extensions - payload that may only have local meaning • Location of an attribute directory • should be given unique OIDs to avoid potential conflicts • Certain extensions can be marked critical - if a Relying Party can’t understand it then it shouldn’t use the cert • Certificate profiles document total payload (covered in Part 2)

14. Background on 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. • OIDs can be associated with: • abstractions - e.g. “the Level of Assurance of this cert” • type identifiers - e.g. “the following object is a pointer of type <X>” • object identifiers - e.g. “this Cert Policy is identified by OID <N>” • Distributed management; each campus typically obtains an “arc”, e.g. 1.3.4.1.16602, and then creates OIDs by extending the arc,e.g 1.3.4.1.16602.1.0, 1.3.4.1.16602.43.10, 1.3.4.1.16.602.10.5.1 • campus should have an OID registrar

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

16. Cert Management • Certificate Management Protocol - for the creation, revocation and management of certs • RA <--> CA • CA <--> browser • browser <--> diskette (!) • Revocation Options - CRL, OCSP • Storage - where (device, directory, private cache, etc.) and how - format (DER, BER, etc.) • related to mobility (covered in Part 2) • Escrow and archive - when, how, and what else needs to be kept • Cert Authority Software or outsource options • Policy Authority and policies

17. Policy - the Establishment of Trust • On what basis does a Relying Party “trust” a CA? • It has some assurance that it knows how it operates (much like life) • At least 4 documents are needed: • The institutional business context • what office is the Digital Credential Authority? • The Certificate Policy • how is a cert issued, what does it mean, how is it managed, etc. • A (set of) Certification Practices Statement(s) • how is the Policy implemented in practice? • A Directory Management Policy • how is data entered or changed? • what data can be released, and under what circumstances? • Bridge Policy Management Authorities need to be able to map your CP/CPS to another CA hierarchy’s CP/CPS • commonality is A Good Thing

18. Certificate Policies Address (CP) • Assurance levels • levels determined by I/A processes and other operational factors • Legal responsibilities and liabilities (indemnification issues) • Relying Party obligations • “By making use of [this] certificate, the Relying Party agrees...” • Operations of Certificate Management Systems • Archiving of CMS records • Auditing requirements • Certificate revocation and renewal requirements • Accompanying Certification Practices Statement(s) define specifics

19. Certification Practice Statements (CPS) • Site specific details of operational compliance with a Cert Policy • Who/what can be a Subject? • Who is responsible for the physical CA, etc.? • How is initial identification/authentication of Subjects accomplished? • Where is the CP stored? • How is revocation requested? • etc. • A single Policy might be referenced by a number of Practice Statements • A single Practice Statement can support several Policies (CHIME) • A Policy Management Authority (PMA) determines if a CPS is an appropriate implementation of a given CP.

20. Directories • Directories (typically LDAP accessible) are needed to: • to store issued certs • to store attributes (eduPerson will be described in Part 2) • MAYBE to store private keys - for the time being • this raises serious privacy concerns • to store the CRL • Certain directory information must be protected • institutional policy, FERPA requirements, User preferences • implement with border directories • ACLs within the enterprise directory • based on PKI cert authentication! • Attribute Authority • a new concept for controlled release of User attributes • proprietary directories

21. PKI Implementation Options • In-source - with public domain or campus unique software • MIT, Columbia, Virginia • In-source - with commercial product • Minnesota • In-&-Out-source - with commercial services • University of California & Verisign • Out-source - a spectrum of services and issues • Texas, UAB • Verisign, Digital Trust, Entrust, Baltimore, etc. etc. • What you do depends on when you do it, cost tradeoffs, etc...

22. Public Domain Alternatives • SSLEAY (Open SSL) • http://www.openssl.org/ • Open CA • http://www.openca.org/docs/mission.shtml • Intel Common Data Security Architecture (CDSA) • http://developer.intel.com/ial/security/ • Mozilla (?) • vandyke and Cygnacom libraries in the public domain for path discovery and validation

23. Trust Chains • Verifying sender-receiver comfort level by finding a common trusted entity • Must traverse perhaps branching paths to establish trust paths • Must then use CRLs etc. to validate certs at each node along path • If policy mapping is indicated by a cert in the path, then validation can be quite complex • Software to discover and validate complex chains is rare (so far) • Current practice avoids this by distributing “trusted authority certs”

24. Inter-organizational trust model components • Certificate Policy and Certificate Practices form the basis for trust • Hierarchies and cross certification form the technical underpinning • Hierarchy starts with a root CA that issues authority certs to other CAs • subordinate CAs may (or may not) do the same • policy and practice conformity is enforced from the top • Certification of a CA by another unrelated CA can link 2 hierarchies • policy and practices must be “mapped” - roughly equivalent • bi-directional or cross-certification forms a bridge between them • a “bridge CA” can link may different hierarchies • 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. Cross-certification • “A” certifies “B” so that “1” can trust certs issued under “B” • however, “3” and “4” can’t establish path to CAs under A • “B” and “C” are cross-certified so all certs in either are trusted

26. A Bridge CA • A “Bridge CA” serves as a clearing house, mapping policy among cooperating CA hierarchies

27. 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 whether trust is appropriate • should address revocation, key usage, basic constraints, policy mappings, etc.

28. Trust Chains • When and where to construct and validate • off-line - on a server - at the discretion of the application • may depend on depth of chain • Some revocations better than others • major (disaffiliation, key compromise, etc.) • minor (name change, attribute change) • Sometimes the CRL can’t be found or hasn’t been updated • OCSP will help this • URI pointer in cert

29. Key issues around “trust” • Trust relationships among autonomous organizations • Chains, bridges • Interoperability of profiles and policies • Interactions with J.Q. Public • People need to learn how to manage these credentials • This will be non-trivial for most people • Implementations must make it as easy (intuitive) as possible • International governance issues • Governmental bodies may get involved • E.g. release of personally identifiable attributes is restricted in Europe • Case law • None yet but “digital signatures” may be a hot area soon

30. All the stuff we don’t know… • Policy languages • automation of policy verification • Mobility - both of certs and Users • one computer with many users • one user with many computers • Path construction in complex trust environments • Operating system and token security issues • Scalability of revocation approaches • User interface !!

31. A few words about User Interface • Primary User tool is the browser, both for getting and using certs. • Issues include: • management of multiple (types of) certs • how can we avoid asking the User to choose which one to offer? • installing or caching “trusted root” certs • alternative to trust chain, or when chain can’t be found • support for “dual certs” (signing and encryption) • ease of use - signing and/or encryption • click here to sign this transaction • click here to check the signature on this page • “certs on demand” - e.g. anonymous certs for library access • Portability and standard O/S interface • Use of “attribute certs” by servers

32. End of Part 1 • Refreshment break . . .