PKI Survey Oasis by liaoqinmei


									PKI Survey

 Chet Ensign
 OASIS Individual Member

Study on the Use of PKI in OASIS Standards
March 26th, 2008
Overall project goals
   Document use & applicability of PKI for
    OASIS standards
   Identify where standards express
    implicit/explicit expectations re PKI
   Identify assumptions re specific
   List explicit standards referenced
   Identify issues of interest to OASIS
   Provide recommendations
Approach taken

   Interview 3 - 5 TC chairs or technical leads
   Determine which TC’s to review;
   Group TCs in categories & evaluate importance
    of security/identity/trust services to each
   Explore archives for discussion of specific
    standards or relevant topics
   Summarize trends, observations, themes &
    provide any recommendations
Insights from the Interviews
Findings from interviews
   Interviews held with:
       Hal Lockhart, Chair, eXtensible Access
        Control Markup Language TC
       John Borras, Chair, Election and Voter
        Services TC
       James Cabrell, Chair, LegalXML
        Electronic Court Filing TC
   Additional email exchanges with
Findings from interviews
   Continuing impression that PKI is
    expensive and difficult
   Assertion that most applications do
    not need bullet-proof identity &
    security services
   Concern that PKI not “scare off”
    users who would otherwise
    implement a standard
Findings from interviews
   Unrealistic to expect that “everything
    will be done the same” - real world
    applications will require mix-and-
    match solutions
   Legal and regulatory environment
    still evolving and risk management
    case for PKI often hard to make
   Key management and revocation
    are real problems in the current
    environment that PKI can address
   TC’s moving from development to
    implementation raise new
    opportunities to “sell” PKI
   Focus on supporting transitions of
    real-world systems over time as they
    evolve to more sophisticated
Insights from TC Reviews
Findings from TC reviews
   68 TC’s reviewed to some level; 55
    explored, 13 in-depth
   How TC’s were selected for review:
       Reviewed membership list for broad
       Scanned email and document archives for
        evidence of substantive discussion
       Decide whether TC’s broad mission
        depended on PKI & identity services for
Findings from TC reviews
   TC’s were grouped along two
       Purpose: spec development,
        framework development & coordination
       Type: service discovery, service
        description, messaging, security &
        access, orchestration & management,
        data content, process description and
Findings from TC reviews
   For reviewed TC’s
       Archives were searched for discussion of
        relevant standards (e.g. PKI, X.509, SAML)
       Archives were searched for discussions of
        relevant topics (e.g. authentication,
        certificates, digital signature)
       Published committee specifications and
        standards were reviewed for same
   Results were tracked in a spread sheet
Findings from TC reviews
   General findings of the review were:
       PKI only seemed directly relevant for 40% of
        reviewed TC’s
       Of those, 66% made minimal to no references
        to PKI and related standards
       PKI-awareness was mixed across purpose:
        framework TC’s seemed especially light
Findings from TC reviews
   Across TC types:
       Data Content TC’s have minimal need
        for PKI and their archives reflect this
       Messaging TC’s have minimal need for
        PKI and their archives reflect this
       Orchestration TC’s have a larger need
        for PKI but 70% did not address it
       Security TC’s have a significant need
        for PKI and most addressed it
   Overall:
       Few standards require PKI -- but few
        solve a complete problem. Need for
        PKI becomes clear in real world
       PKI predominantly addressed by TC’s
        referenced in other specifications.
        Ensuring PKI is thoroughly explained in
        the former will help its adoption by the
    Certificate management and revocation
     present an opportunity for outreach
     and education on sophisticated issues
     not well understood
Conclusions & Recommendations
   On use & applicability:
       Multiple approaches can be used to
        deliver business functions provided by
        PKI. Most TCs do not wish to constrain
        implementation options
       TC’s closest to identity, trust & security
        are very familiar with PKI. Ensuring
        support in their specifications will make
        adoption eaiser for others
   On explicit/implicit assumptions:
       Explicit assumptions are obvious;
        implicit harder to gauge, however by
        any measure, assumptions were low
       TC’s providing messaging,
        orchestration and security & access --
        the basic infrastructure services on
        which others rely -- represent the best
        opportunities for outreach and
   On methods & systems used
       Very little in the way of assumptions on
        how PKI should be implemented
       TCs with most detailed work product
        (e.g. ebXML CPPA, SAML) offer an
        excellent template generic
        documentation sets that other TCs can
        incorporate into their standards
   On specific references
       By and large, OASIS standards do not
        reference PKI standards
       Those that do are the security
        standards: SAML, WS-S, etc.
       Providing a set of normative references
        pre-packaged for TCs could help
   On barriers to deployment
       PKI is not one specification but rather an
        umbrella for manh; a TC cannot simply
        reference PKI and have a clear statement of
       No single definition of what constitutes a PKI
       TC’s have to do additional work to explain
        what a PKI means in the context of their
    Potential customers do not have ways
     to assess risk and need in practice
     while government has not made the
     obligations and liabilities clear
    Technical staff do not have clear
     understanding of the problem space
    Interoperability problems still plague
     the products on the market
   Make PKI easier to understand
       Assume lack of familiarity; explain
        terms & concetps t
       Define what constitutes a PKI
       Tie capabilities to functional needs
        customers understand (e.g.
        authentication, digital signature)
       Develop awareness of risks & less
        understood concerns
   Make PKI easier to incorporate
       Create template PKI documentation
       Build PKI profiles
       Ensure PKI is well presented in
        security & infrastructure TC’s that other
        standards typically reference
   Make PKI readily available
       Collaborate with framework TC’s to
        develop PKI implementation roadmaps
        that suit their objectives
       Use calls for comment and reviews as
        opportunities to evaluate standard’s
        use of PKI and reach out if appropriate
   Make PKI easier to use
       Promote interoperability solutions
        where PKI works in conjunction with
        simpler solutions
       Publish a position statement of
        expectations for interoperability of PKI
Wrap up
   PKI struggles with many of the same
    identity problems that plagued SGML in
    its early days
   PKI advocates can learn from the
    approaches taken by XML:
       Focus on business problems
       Communicate to a ess technical audience
       Ensure that PKI can co-exist with less
        rigorous solutions
Thank you for your time.

To top