PKI Solutions: Buy vs. Build

1. PKI Solutions: Buy vs. Build David Wasley, U. California (ret.) Jim Jokl, U. Virginia Nick Davis, U. Wisconsin

2. Agenda • Why are we here? • Why do you want a PKI? • Implementation Models • And a word or 2 about trust model(s) • Functional Requirements • Some options for Higher Ed. • Case study: University of Wisconsin • Case study: University of Virginia • Q & A

3. Why are we here? • Asymmetric cryptography is a tool • Information integrity and/or security • PKI adds identity context & trust model • Deployment has been slow but there are new drivers • e-business and accountability • Scalable secure and/or trusted email • High assurance digital credentials

4. Why do you want a PKI? • First step in implementation planning • Typical application areas: • Identity credentials • Scalable secure email (s/mime) • digital document signing • Other apps include: • Document integrity (web sites, digital archive) • Infrastructure protection (IPSEC)

5. Implementation Models • Many different ways to get PKI services • No one perfect way for all campuses • Cost models may vary greatly depending on size of campus • Biggest differences are • functional capabilities & flexibility • a priori “trusted certificates”

6. Implementation Models (cont.) • Stand-alone PKI for local use • PKI as part of a larger community • Commercial PKI services • Partial outsource • Full outsource • Bridged PKI

7. Stand-alone PKI • Root CA cert is distributed as needed • “Policy” is campus business rules • “Trust” is implicit • All support is local

8. Part of a PKI Hierarchy • Enables trust across communities • Common root cert is distributed as needed • May be a challenge • “Policy” is defined by the common TA

9. PKI Trust Model(s) • Important if certificates are to be used with external parties • “Trust Anchor” defines certificate policy for a homogeneous PKI • Relying Parties must • Understand TA CP • Identify which policy(s) it will accept • Hold a copy of the TA (root CA) certificate

10. Bridged PKIs • Enables trust across communities • Each campus retains its own trust anchor • Policy is mapped through the Bridge • Bridges can/will interconnect too

11. What a Bridge look like to RP • RP trusts its TA tomap “trust” (CP OIDs) appropriately • TA trusts Bridge tomap “trust” appropriately • Policy is critical!

12. Commercial PKI Service • Trust across Provider’s customers • Policy is Provider’s CP • Most Providers placeTA certs in browsers, etc. • Apps a priori trust them (?) • Campus may still need to support the RA function • If not, how does RA relate to campus Id Mgmt system?

13. Functional Requirements • Multiple certs per individual • Different cert types • Dual certs and key escrow • Normal versus high assurance certs • Certificate extensions and/or SIA • Real-time certificate status • Subordinate CAs • Infrastructure certs • Transient certs

14. Some options for Higher Ed. • U.S. Higher Ed. Root (USHER) • Higher Ed. Bridge CA (HEBCA) • Commercial PKI services • Widely varying features & per user costs • EDUCAUSE Identity Management Services Program (IMSP)

15. Case Studies • University of Wisconsin Nick Davis, PKI Program Manager UW, Madison • University of Virginia Jim Jokl, Director Communications and Systems

16. Q & A • dlwasley@earthlink.net • ndavis1@wisc.edu • jaj@virginia.edu