pki solutions: buy vs. build
DESCRIPTION
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. - PowerPoint PPT PresentationTRANSCRIPT
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 to
map “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
