VIEWS: 13 PAGES: 6 POSTED ON: 3/24/2011
OASIS – PKI TC Face to face Meeting –and Conference Call Notes September 30, 2003 D-R-A-F-T PKI Technical Committee Face to Face Meeting Computer Associates Herndon Virginia Attendees: Members: In Herndon: Steve Hanna John Sabo June Leung Paul Evans Sharon Boeyen Ross Smith By Telephone: Peter Doyle Jeff Stapleton Terry Leahy Jeremy Hilton Prospective Member: By Telephone: Phil Fulchino Members Not Present: Krishna Yellepeddy John Messing Ann Terwilliger Cliff Thompson Hemant Adarkar Observer not Present: Tony Nadalin 1. Meeting Notes The Minutes of August 20 meeting approved unanimously, as amended. 2. Reports and General Discussion Sharon Boeyen reported on her attendance at ETSI/CEN meetings in France last week. There appears to be a movement in the European Union toward de- emphasizing digital signatures per se and a and new emphasis on use of digital signatures for e-authentication, e-invoicing (source, origin, and business authentication) important because of VAT issues). Discussion on goals of the PKT TC as they relate to the obstacles survey. What are we trying to accomplish? It was agreed that the broad goals of the TC are adequate at this time. With respect to the face to face meeting, it was also agreed that stated goals are adequate at this point in the meeting. However, we may want to revisit them as we work through the day. 3. Discussion/ Review results of surveys Steve Hanna reviewed the survey findings. There was discussion regarding the obstacles ranking, their relative importance in the survey findings, and their interrelationships. Ross Smith discussed PKI applications in Canada, ePass, with private keys stored on profile servers, with authentication to individual agencies via shared secrets. Government of Canada is converging to a common registration system. Server-based PKI can be useful in supporting large bodies of typical users (as opposed to smaller groups within an enterprise, etc.). Discussion on the inter-relationship of the obstacles; different understanding of the term “applications” as the text comments focused on end user applications such as email or Microsoft applications rather than server applications. Discussion move to obstacles by rank order, with emphasis on initial obstacle, Software applications don’t support it [PKI].” Discussion of COTS/desktop applications and server/mainframe applications. Issues: how do you develop standards-based API’s which would remove customers from reliance on one vendor’s API? Libraries may be the better location for interoperability…you can buy, lease, code or use any open source library, but to show you are OASIS PKI compliant, you would demonstrate this via test suites, etc. Application vendors could select whatever libraries they wish to use. NIST doing work on PKI test suites – e.g., for Path Validation, which is also useful in promoting applications support. They will be using Common Criteria protection profiles One approach: the TC might take steps to identify and describe the high level functionality should be given “even treatment” for broad applications support. An example to follow might be the Biometrics’ Consortium’s development of the Bio API as well as the ANSI standard for biometrics security. To follow this approach, the TC might speak to application vendors and users. An additional question for application vendors is their willingness to adopt a common API. Another source of information is results of the EEMA PKI interoperability challenge as well as results of World EMA interoperability testing. Paul Evans will locate and make the US EMA results available to the TC. Likewise, the implications of Directory interoperability were not heavily addressed in the TC survey text comments, yet are serious problems for implementers in the U.S. and elsewhere. Other issues are LDAP deficiencies and OID issuance (e.g., by NIST). Three major Directory challenges are protocol (X.500 chaining vs. LDAP referral); naming (because of role of names in Directory searches; and Schema support for searching (e.g. searching for CRL in an object class directory, but not finding it because object was not properly stored). For better application support, we need to have basic agreement on standards and policies. Without these standards, costs and barriers to deployment will by definition be significantly higher. For PKI’s use of directory, when searching for an intermediate certificate to build a path you always have a DN of issuer or subject, and you need address to go for CRL, using CRL distribution points to find it, other cert issuer name. Biggest stumbling block is end- user encryption certificates. Another issue: when people say software applications don’t support it, do we know what people mean – e.g., what vendors think versus what users think. NIST (Tim Polk) is developing profiles for using PKI for particular functions (e.g., IPSEC, VPN) –we might develop/foster development of profiles for certain uses, with business explanation as well as technical. Can vendors agree on standard signed object content description (like MIME message with body parts and signatures etc.)? CEN may have a document addressing such an issue. Also, OASIS Digital Signature Services TC is doing work in this area. Other barriers: native format of documents which are to be signed (e.g., in Canada, using Word as text editor). A possible approach for the TC is to focus on a few applications to start: secure document signing, email and e-commerce (provided we narrow down the e-commerce/e- government applications to make this manageable). There is a set of work already done on email, less so in document signing and e-commerce. Application areas where email signing/encrypting is used– in Canada primary focus is encryption for emails for cross-border protection. In this scenario issues are: email software used, whether PKI support is available (e.g. CA), usability across these email systems, availability of certificates outside organizations for security purposes – this could be interesting study, as there are more issues here than just PKI. Possibly focus on successful deployments: Johnson & Johnson, FUNDServ, The Open Group to examine successful deployments which may assist us in determining areas to examine. Issues of interest: COTS applications vs. building applications using PKI. Should we talk to applications vendors regarding their perspectives? Again, we need to think through what we mean by “interoperability” – greater than vendor X CA interoperating with vendor PKI client – we are talking about business issues, policies, technical interoperability from client to a number of CA’s, etc. Specificity may be warranted, e.g., in addressing contract signing, document signing before dissemination (e.g., Web-posted information), and forms signing (e-forms). In each area we can discuss successful deployments, barriers, what is lacking, and ways to address these problems. 4. Possible Action Discussion 1. Develop specific profiles or guidelines? Perhaps we need to point to work needed, and where available, point to completed profiles and guidelines under development which are addressing these. A question was raised re meaning of profile – different characteristics depending on situation in which profile is used. Profiles would be developed for messaging, document signing, e- commerce. Where various products are available, e.g., secure messaging products, it may be needed to establish an underlying basic profile which would at least establish a baseline for interoperability. Perhaps we should build or foster the development of a profile of what needs to be done…then see how it maps against specific products Agreement: exhort industry to develop appropriate profiles and look to existing bodies, perhaps EEMA, The Open Group and others, to undertake that work. Issues can be developed which will address writing a secure email messaging guideline and/or profiles 2. Provide interoperability tests and testing events to improve interoperability – messaging, document signing, e-commerce. Possible role may be to work with NIST to address conformance on certificate path validation (not construction) – they are doing test suites as well as protection profiles. Branding may be appropriate to document that interoperability has been achieved, and we can work with other organizations to promote a branding program. This may include deployment guidelines as well. We may seek a forum in which to discuss document signing issues in conjunction with the PKI Research Workshop, sponsored by NIST in Spring 2004. NIST has asked OASIS PKI TC to be co-sponsor. There is another event, XML2003 in Philadelphia, to be held in December 2003. If there are issues that are problems, perhaps as simple as lack of understanding of PKI – document signing for integrity purposes only, timestamp, access to facilities for validation, etc – basic PKI functions – what does PKI enablement mean for applications. 3. Providing “cookbook” with easy steps for building a simple PKI. Doesn’t look like there is a need for TC to take action, other than point to available resources. 4. Provide free software and free CA’s so people can set up a test PKI with little or no cost. No need for TC to take action other than point to available resources. 5. Return on investment – point to PKI Forum ROI paper and vendor examples. We also need to understand PKI as a supporting infrastructure for risk management, particularly in situations where vulnerabilities exist, which equate to financial or other risk, PKI-based solutions can effectively mitigate risk by providing security functionality. From UK perspective, one major inhibitor is cost as well as difficulty of end user is to get a certificate. So ROI on PKI per se is not issue. We may need to look at transaction-based capability. For example, in situations high value transactions may be require certificates…but question is who will pay for this? How can we reduce cost of provisioning this infrastructure. Jeremy Hilton is developing white paper addressing such issues. 6. Interoperable Policies – no common agreement on the term “policy” – e.g., CP and CPS among government users tend to be similar and focused on assurance issues; but CP in commercial circles is different – may be as simple as a list of applications supported by the certificate. Major issue is typically not the technology (e.g., as in technical cross-certification) but the policies. Bottom line of our work: We have developed a valuable survey, we are characterizing and analyzing what we learned, we are identifying major obstacles, and there are specific steps we believe need to be done to address them. Survey text comments may be de-identified and organized into categories. We could then respond to those where information is available to adequately deal with them. For example, path validation was directly and indirectly raised, NIST’s work can be referenced as a solution. 5. Agreements of TC and Motions o Who will write draft Action Plan – Steve Hanna Who we should ask to review, comment on, and/or endorse plan and/or join the PKI TC – NIST, selected individuals, Jeremy at ISSE can include reference in his panel – can involve key stakeholders Who will contact them and how we will convince them to act – Jeremy will contact EEMA, Paul Evans NIST PKI TWG, and others in various meetings. It was agreed that TC members will conduct one on ones with selected individuals in October, with public review of the draft action plan in November timeframe. The following actions postponed until action plan has been drafted, reviewed and agreed upon. o who must take action to execute plan and what action they must take o how we will convince them to do so o rollout, press, and marketing for plan Motion: Adopted unanimously: Place Follow-Up Survey results on the Web Site and invite participation to join the TC and work with us to address obstacles identified in the survey; discuss our survey with individuals and with organizations such as NIST’s PKI TWG (Oct 15 meeting –Paul Evans to present), EEMA, ABA, Chairs of the PKIX WG; and seek comments from survey respondents and selected individuals. Motion: Adopted unanimously. Request that the PKI Members Section Steering Committee provide consultant services to support TC initiatives in support of this project, including enhancing the Web site, supporting the categorization of information and content, not to exceed $5000USD, with tasks determined by the TC. Next Meeting: A call for the next meeting date proposed for week of October 20 will be sent to the email list. Meeting Adjourned at 4:30PM Meeting notes prepared by John Sabo.
"OASIS – PKI TC"