1. HEPKI-TAG UPDATE Jim Jokl University of Virginia jaj@Virginia.EDU

2. 2 Higher Education PKI Activities - HEPKI Sponsors Internet2, EDUCAUSE, CREN, NET@EDU HEPKI - Technical Activities Group (TAG) Open-source PKI software Certificate profiles Directory / PKI interaction Validity periods Client customization issues Mobility Inter-institution test projects Technical issues with cross-certification www.educause.edu/hepki

3. 3 Certificate Profile Work A per-field description of certificate contents Standard and extension fields Criticality flags Syntax of values permitted per field Spreadsheet & text formats Higher education profile repository http://middleware.internet2.edu/certprofiles

4. 4 Certificate Profiles Assortment of EE/CA certificates From eight institutions CRLs Issuer/Subject field naming X.500-style Distinguished Names Subject fields with real names Anonymous names Little use of constraint extensions

5. 5 Certificate Profiles Validity Period Wide variation from per-session to one year Long term: expiration synchronized to semester Assurance level indicator Explicit extension Policy OID Key usage Some certificates employ Key Usage field Variation on criticality setting Encryption and private key escrow

6. 6 Certificate Profiles Domain Component Naming Some certificates also use DC naming Encode domain names into X.500-type name fields (dc=Internet2, dc=edu) (rfc-2247) Issuer and Subject fields HEPKI-TAG Recommendation Use DC naming in the Subject and Issuer fields Place DC components in most significant part of the name Use more specific pointers to information before using DC names in applications Test for problems with devices

7. 7 Certificate Profiles: Some Issues Profile Convergence Shared desire to minimize the number of profiles in the community –Aid new PKI implementations –Ease policy mapping –Promote interoperability What is the right number of profiles? –What are the applications? Importance of convergence? If you are issuing certificates, please email one so that we can include it in the repository

8. 8 PKI Complexity and Applications You often hear of PKI as a solution for: Authentication for high-assurance processes –Funds transfer –Medical records –Student grades Digital signatures –Contracts –Other legal documents But, can’t it also be a good fit as a technology that is better than passwords but less than a high- assurance CA?

9. 9 PKI-Light Full function but lightweight  A normal PKI technical infrastructure  Authenticate EEs  Issue certificates, perhaps revoke certificates  A comparatively simple certificate profile  Support applications, directories, etc  A lightweight administrative/policy structure  Supports applications without high assurance needs  One or two paragraph certification policy

10. 10 PKI-Light Project Assumptions Initial applications  Web application authentication  Secure e-mail S/MIME Operational issues  No requirement for revocation  No requirement for separate signing and encryption certificates  On-line CAs are acceptable  Single PKI-Light policy OID  Simple assurance level requirement

11. 11 PKI-Light Certificate Profile  Version 3 certificates  Issuer: normal as per TAG DC Naming recommendation  Validity: one year  Subject  Name as per HEPKI-TAG DC Naming recommendation  Include email  Other criteria such as name uniqueness, practices, etc  Basic Constraints: CA=false  Certificate Policy OID  CPS Pointer: yes  Subject Alt Name: email address  http://middleware.internet2.edu/hepki-tag/pkilite-profile-recent.html http://middleware.internet2.edu/hepki-tag/pkilite-profile-recent.html

12. 12 PKI-Light: next steps Learn from Pilot/Demonstration Projects Web authentication Electronic mail Directory interaction Insert your project here Participation Want more schools and more users Help break some of the myths that PKI is too hard or too costly to implement

13. 13 PKI Mobility Options Hardware tokens Smart cards, USB devices, iButtons Key-pair generation location Drivers, software quality, cost Software-based Mobility passwords to download from a store or directory proprietary roaming schemes IETF SACRED working group established Integration

14. 14 CA Private Key Protection Issues CA Private Key is the root of all trust Storage options –Clear text on disk –Encrypted storage on disk –On hardware device Physical protection of CA –Locked doors and racks –OS Configuration Multi-level solution Collection of information for new PKI sites

15. 15 Discussions and Projects Higher Education PKI Applications General web authentication Access to course materials S/MIME etc middleware.internet2.edu/hepki-tag/TAG-PKI-Apps3.xls Certificate Profile Maker Web interface Generates XML PKI pilot and demonstration site

16. 16 Discussions and projects HEPKI-TAG Website Recommendations Information for those starting on PKI –References –How-to information –Certificate profiles –Minutes and survey data www.educause.edu/hepki/ Please email feedback

17. 17 Project Participation Much work remains Research and recommendations Pilot projects Mobility etc Consider participating in HEPKI-TAG if you are working on a PKI deployment

18. 18 Where to watch middleware.internet2.edu www.educause.edu/hepki www.cren.net/ca NET@EDU PKI for Networked Higher EdNET@EDU www.educause.edu/netatedu/groups/pki PKI Labs middleware.internet2.edu/pkilabs www.pkiforum.org