160 likes | 256 Vues
Explore the debate between buying and building PKI solutions for Higher Education institutions. Understand implementation models, trust models, functional requirements, and case studies from University of Wisconsin and University of Virginia.
E N D
PKI Solutions: Buy vs. Build David Wasley, U. California (ret.) Jim Jokl, U. Virginia Nick Davis, U. Wisconsin
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
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
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)
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”
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
Stand-alone PKI • Root CA cert is distributed as needed • “Policy” is campus business rules • “Trust” is implicit • All support is local
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
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
Bridged PKIs • Enables trust across communities • Each campus retains its own trust anchor • Policy is mapped through the Bridge • Bridges can/will interconnect too
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!
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?
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
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)
Case Studies • University of Wisconsin Nick Davis, PKI Program Manager UW, Madison • University of Virginia Jim Jokl, Director Communications and Systems
Q & A • dlwasley@earthlink.net • ndavis1@wisc.edu • jaj@virginia.edu