PKI: News from the Front and views from the Back

1. PKI: News from the Frontand views from the Back Ken Klingenstein, Project Director, Internet2 Middleware Initiative Chief Technologist, University of Colorado at Boulder

2. Agenda • X.509 Certificates • The Technical Infrastructure - CRL’s, CA software, Directories, Applications, Mobility • The Policy Infrastructure- policies, practices, paths, lifetimes • Authorization - complex, high-payoff • Next steps

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

4. X.509 certs • purpose - bind a public key to a subject • standard fields • extended fields • profiles • client and server cert distinctions

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

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

7. The Technical Infrastructure • Certificate Revocation Lists • Cert management • Directories • Certificate Enabled Applications • Mobility

8. Certificate Revocation Lists (CRL) • Purpose - to post revoked certs by serial number • Reasons for revocation include major (disaffiliation, key compromise, etc.) and minor (name change, attribute change) • Path construction - to build the chain of trust from the issuer CA to a CA trusted by the relying party • Certificate validation - uses path to determine if cert is valid • Application and user responses - what to do if revoked? What to do if unknown? Does the app or the user decide?

9. Cert Management • Certificate Management Protocol - for the creation and management of certs • OCSP - on-line CRL plus…. • Storage - where (device, directory, private cache, etc.) and how - format • escrow and archive - when, how, and what else needs to be kept • Cert Authority Software • Authority and policies

10. CA Software • SUN/Netscape • IBM • W2K Certserv

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

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

13. Cert-enabled applications • Browsers • S/MIME email • IPsec and VPN • Globus

14. Mobility • smart cards and USB devices • KX.509 for authenticated delivery of certs to users • storing certs - integration of certificate stores • storing and using keys

15. Trust model components • Client versus Server distinctions • Certificate Profiles - syntax, semantics and uses of specific types of certificates • Certificate Policy - uses of particular certs, assurance levels for I/A, audit and archival requirements • Certificate Practice Statements - the nitty gritty operational issues • Trust Chains and Path Math

16. 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 being set up

17. Certificate Policies • 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

18. Certificate Practice Statements • operational aspects that allow lawyers to decide who to trust • must cover I/A, Cert Management, underlying operations

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

20. Hierarchies vs Bridges • a philosophy 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

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

22. PKI Activities • DLF: UCOP, Columbia, soon Minnesota • FPKI (http://csrc.nist.gov/pki/twg/welcome.html) • PKI for NGI, Globus • net@edu within EDUCAUSE • CREN CA • In-sources - MIT, Michigan • Out-sources - Pittsburgh, Texas • PKIforum • W2K

23. Next Steps • PKI Labs • long-term research agenda, includes path math, open standards and reference implementations • ATT catalyst funding with other investments expected • a national advisory board • RFP next month • Net@edu • Fed-ed meetings • workshops

24. Next Steps • 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