Upload
geoffrey-matthews
View
217
Download
0
Tags:
Embed Size (px)
Citation preview
PKI Survey
Chet EnsignOASIS Individual Member
Chet EnsignOASIS Individual Member
Study on the Use of PKI in OASIS StandardsStudy on the Use of PKI in OASIS StandardsMarch 26th, 2008March 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
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
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 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