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 methods/systems 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 others 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 Opportunities 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 Opportunities Focus on supporting transitions of real-world systems over time as they evolve to more sophisticated scenarios 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 participation Scanned email and document archives for evidence of substantive discussion Decide whether TC’s broad mission depended on PKI & identity services for success Findings from TC reviews TC’s were grouped along two dimensions: Purpose: spec development, framework development & coordination Type: service discovery, service description, messaging, security & access, orchestration & management, data content, process description and coordination 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 Opportunities Overall: Few standards require PKI -- but few solve a complete problem. Need for PKI becomes clear in real world applications PKI predominantly addressed by TC’s referenced in other specifications. Ensuring PKI is thoroughly explained in the former will help its adoption by the latter Opportunities Certificate management and revocation present an opportunity for outreach and education on sophisticated issues not well understood Conclusions & Recommendations Conclusions 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 Conclusions 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 collaboration Conclusions 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 Conclusions 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 adoption Conclusions 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 expectations 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 standard Conclusions 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 Recommendations 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 Recommendations 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 Recommendations 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 Recommendations 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 tools 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.
Pages to are hidden for
"PKI Survey Oasis"Please download to view full document