OASIS – PKI TC by wuyunqing


									                                        OASIS – PKI TC
                        Face to face Meeting –and Conference Call Notes
                                      September 30, 2003

PKI Technical Committee Face to Face Meeting
Computer Associates
Herndon Virginia



       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

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-

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

4. Provide free software and free CA’s so people can set up a test PKI with little or no

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


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.


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.

To top