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

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

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

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

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

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

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

9. 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?

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

11. CA Software SUN/Netscape IBM W2K Certserv

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

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

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

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

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

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

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

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

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

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

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

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

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

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