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

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.