Docstoc

PKI Solutions_ Buy vs. Build - EDUCAUSE

Document Sample
PKI Solutions_ Buy vs. Build - EDUCAUSE Powered By Docstoc
					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 to
    map “trust”
    appropriately
   Policy is critical!
        Commercial PKI Service
   Trust across Provider’s
    customers
       Policy is Provider’s CP
   Most Providers place
    TA 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

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:3
posted:1/4/2013
language:English
pages:16