re:[pki-ms] Proposed charter for OASIS EKMI TC

[Stephen Wilson <swilson@lockstep.com.au>]

Thanks Dee.

I know there is a list for posting comments, and I plan to do that.  But 
I'd like to direct my initial response to the new EKMI to the old PKI TC 
first, to see if I am on the right track.  

Frankly I am disappointed with the Charter.  When the Enterprise Key Mgt 
TC was first mooted I remember commenting on a conference call that the 
draft charter overly de-emphasised PKI.  I was assured that both 
symmetric and asymmetric key management would be covered.  But the formal 
charter released below pays no ongoing attention to asymmetric key mgt at 
all.  It will leave the inevitable impression that OASIS does not care 
about PKI anymore, which in turn will add to the false impression across 
business at large that PKI doesn't matter.  We are throwing the baby out 
with the bath water.  At the very least we need to be much more sensitive 
to the fact that in many quarters, any amiguous messages about PKI are 
interpreted as meaning PKI is dead. 

I strongly disagree with the barely implicit proposition that there is 
nothing left to do in PKI.  Across the board we are still faced with fear 
and uncertainty in PKI, resistance to its take up, confusion as to how 
PKI relates to ID technologies like smartcards, and a lack of clarity 
about what to with it at the application level.  Ironically, many vendors 
report a resurgence in PKI, but at the education, policy and strategy 
levels, the field is in need of innovation and new directions. 

I think there is a huge ammount of work to be done in embedded PKI, in 
new certificate models, and interoperability.  In response to recent 
personal encounters with confused clients I wrote a recent one page paper 
on interoperability, which I think serves to show how much work is yet to 
be done;  please see "Babystep No. 5" at 
http://www.lockstep.com.au/library/babysteps.

Specifically, the statement coming at the end of the new charter, 
that "the goals of [EKMI] potentially may fulfill some of the goals in 
the charter of the PKI TC" is unsubstantiated.  Education and the 
development of applications are still major works in progress from the 
PKI Action Plan, but neither will be addressed in the new TC.  It might 
be a good idea to review the Action Plan in this context. 

And where do we think all of this will leave the Third International PKI 
Survey?  

I appreciate that the PKI TC is stalled, but I would like us to address 
that issue directly, rather than perpetuating the stagnation by simply 
moving onto something different.  If the PKI TC cannot be sustained, then 
it is important that the complex reasons for this be properly understood 
and documented, rather than passively allowing the old TC to morph into 
something quite different to do with symmetric keys. 

Cheers, 

Stephen Wilson.



Lockstep 
www.lockstep.com.au

11 Minnesota Ave
Five Dock NSW 2046
Australia

P +61 (0)414 488 851

--------------------

About Lockstep
Lockstep was established in early 2004 by noted authentication expert 
Stephen Wilson, to provide independent specialist advice and analysis 
on identity management, PKI and smartcards.  Lockstep is also 
developing unique new smartcard technologies to address transaction 
privacy, phishing, pharming and spam.




 
> FYI
> 
> -------- Original Message --------
> Subject: Proposed charter for OASIS EKMI TC
> Date: Wed, 08 Nov 2006 18:24:53 -0800
> From: James Bryce Clark <jamie.clark@oasis-open.org>
> To: members@lists.oasis-open.org,  tc-announce@lists.oasis-open.org
> CC: Arshad Noor <arshad.noor@strongauth.com>,  Mary McRae 
> <mary.mcrae@oasis-open.org>
> 
> To: OASIS Members
> 
>    A draft TC charter has been submitted to establish an Enterprise
> Key Management Infrastructure (EKMI) Technical Committee at OASIS.
> We circulate such draft charters for member review and comments, in
> accordance with Section 2,2 of the OASIS TC Process rules:
>    http://www.oasis-open.org/committees/process.php#2.2
> The proposed charter below is open for comment. The comment period
> shall remain open until 11:45 pm ET on 22 November 2006.
> 
>    OASIS maintains a mailing list for the purpose of submitting
> comments on proposed charters. Any OASIS member may post to this
> list by sending e-mail to:
>    oasis-charter-discuss@lists.oasis-open.org.
> All messages will be publicly archived at:
>    http://lists.oasis-open.org/archives/oasis-charter-discuss/
> 
> Members who wish to receive these messages via e-mail must join the
> group by selecting "join group" on the list's home page:
> 
> http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/.
> Employees of organizational members do not require primary
> representative approval to subscribe to the oasis-charter-discuss
> e-mail.
> 
>    A telephone conference will be held among the Convener, the OASIS TC
> Administrator, and those proposers who wish to attend shortly after
>   the close of the comment period.  The time and call-in information
> will be noted on the oasis-charter-discuss list and home page.
> 
>    We encourage member comment, and ask that you note the name of
> the proposed TC (EKMI) in the subject line of your email message.
> 
>    Best regards   JBC
> 
> ~ James Bryce Clark
> ~ Director of Standards Development, OASIS
> ~ http://www.oasis-open.org/who/staff.php#clark
> ~ jamie.clark@oasis-open.org
> 
> ====
> PROPOSED CHARTER
> FOR REVIEW AND COMMENT
> OASIS ENTERPRISE KEY MANAGEMENT INFRASTRUCTURE TECHNICAL COMMITTEE
> 
> Name
> 
> OASIS Enterprise Key Management Infrastructure (EKMI) TC
> 
> Statement of Purpose
> 
> Public Key Infrastructure (PKI) technology has been around for more
> than a decade, and many companies have adopted it to solve specific
> problems in the area of public-key cryptography.  Public-key
> cryptography has been embedded in some of the most popular tools --
> web clients and servers, VPN clients and servers, mail user agents,
> office productivity tools and many industry-specific applications --
> and underlies many mission-critical environments today.
> Additionally, there are many commercial and open-source
> implementations of PKI software products available in the market
> today.  However, many companies across the world have recognized
> that PKI by itself, is not a solution.
> 
> There is also the perception that most standards in PKI have already
> been established by ISO and the PKIX (IETF), and most companies are
> in operations-mode with their PKIs -- just using it, and adopting it
> to other business uses within their organizations. Consequently,
> there is not much left to architect and design in the PKI community.
> 
> Simultaneously, there is a new interest on the part of many
> companies in the management of symmetric keys used for encrypting
> sensitive data in their computing infrastructure. While symmetric
> keys have been traditionally managed by applications doing their own
> encryption and decryption, there is no architecture or protocol that
> provides for symmetric key management services across applications,
> operating systems, databases, etc. While there are many industry
> standards around protocols for the life-cycle management of
> asymmetric (or public/private) keys -- PKCS10, PKCS7, CRMF, CMS, etc.
> -- however, there is no standard that describes how applications may
> request similar life-cycle services for symmetric keys, from a
> server and how public-key cryptography may be used to provide such
> services.
> 
> Key management needs to be addressed by enterprises in its
> entirety -- for both symmetric and asymmetric keys.  While each type
> of technology will require specific protocols, controls and
> management disciplines, there is sufficient common ground in the
> discipline justifying the approach to look at key-management as a
> whole, rather than in parts.  Therefore, this TC will address the
> following:
> 
> Scope
> 
> A) The TC will define the request/response protocols for:
> 
> 1. Requesting a new or existing symmetric key from a server;
> 2. Requesting policy information from a server related to caching of
> keys on the client;
> 3. Sending a symmetric key to a requestor, based on a request;
> 4. Sending policy information to a requestor, based on a request;
> 5. Other protocol pairs as deemed necessary.
> 
> B) To ensure cross-implementation interoperability, the TC will
> create a test suite (as described under 'Deliverables' below) that
> will allow different implementations of this protocol to be
> certified against the OASIS standard (when ratified);
> 
> C) The TC will provide guidance on how a symmetric key-management
> infrastructure may be secured using asymmetric keys, using secure
> and generally accepted practices;
> 
> D) Where appropriate, and if possible in conjunction with other
> standards organizations that focus on disciplines
> outside the purview of OASIS, the TC will provide input on how such
> enterprise key-management infrastructures may be managed, operated
> and audited;
> 
> E) The TC may conduct other activities that educate users about,
> and promote, securing sensitive data with appropriate cryptography,
> and the use of proper key-management techniques and disciplines to
> ensure appropriate protection of the infrastructure.
> 
> List of Deliverables
> 
> 1. XSchema Definitions (XSD) of the request and response protocols
> (by April 2007)
> 2. A Test Suite of conformance clauses and sample transmitted keys
> and content that allows for clients and servers to be tested for
> conformance to the defined protocol (by September 2007)
> 3. Documentation that explains the communication protocol (by
> April 2007)
> 4. Documentation that provides guidelines for how an EKMI may be
> built, operated, secured and audited (by June 2007)
> 5. Resources that promote enterprise-level key-management: white
> papers, seminars, samples, and information for developer and public
> use. (beginning January 2007, continuing at least through 2008)
> 
> Anticipated Audiences:
> 
> Any company or organization that has a need for managing
> cryptographic keys across applications, databases, operating systems
> and devices, yet desires centralized policy-driven management of all
> cryptographic keys in the enterprise. Retail, health-care,
> government, education, finance - every industry has a need to
> protect the confidentiality of sensitive data. The TC's
> deliverables will provide an industry standard for protecting
> sensitive information across these, and other, industries.
> Security services vendors and integrators should be able to fulfill
> their use cases with the TC's key management methodologies.
> Members of the OASIS PKI TC should be very interested in this new TC,
> since the goals of this TC potentially may fulfill some of the
> goals in the charter of the PKI TC.
> 
> Language:
> 
> English
> 
> IPR Policy:
> 
> Royalty Free on Limited Terms under the OASIS IPR Policy
> 
> ----
> Additional Non-normative information regarding the start-up of the TC:
> 
> a. Identification of similar or applicable work:
> 
> The proposers are unaware of any similar work being carried on in
> this exact area.  However, this TC intends to leverage the
> products of, and seek liaison with, a number of other existing
> projects that may interoperate with or provide functionality to the
> EKMI TC's planned outputs, including:
> 
> OASIS Web Services Security TC
> W3C XMLSignature and XMLEncryption protocols and working group
> OASIS Digital Signature Services TC
> OASIS Public Key Infrastructure TC
> OASIS XACML TC (and other methods for providing granular
> access-control permissions that may be consumed or enforced by
> symmetic key management)
> 
> b.  Anticipated contributions:
> 
> StrongAuth, Inc. anticipates providing a draft proposal for the EKMI
> protocol, at the inception of the TC.  The current draft can be
> viewed at:
> 
> http://www.strongkey.org/resources/documentation/misc/skcl-sks-
protocol.html
> and a working implementation of this protocol is available at:
>    http://sourceforge.net/projects/strongkey for interested parties.
> 
> c. Proposed working title and acronym for specification:
> 
> Symmetric Key Services Markup Language (SKSML), subject to TC's
> approval or change.
> 
> d.  Date, time, and location of the first meeting:
> 
> First meeting will be by teleconference, with an optional face-to-
> face gathering as one conference call node, at:
> Date:  [December ____, 2006]
> Time:  [____ UTC]
> Call in details'; to be posted to TC list
> F2F Location:  San Francisco Bay Area.  StrongAuth has agreed to
> host this meeting.
> 
> e. Projected meeting schedule:
> 
> Subject to TC's approval, we anticipate monthly telephone meetings
> for the first year. First version of the protocol to be voted on by
> Summer 2007. StrongAuth is willing to assist by arranging for the
> teleconferences; we anticipate using readily available free
> teleconference services.
> 
> f. Names, electronic mail addresses, of supporters:
> 
> Ken Adler, individual member, ken@adler.net
> June Leung, FundSERV, June.Leung@FundServ.com
> John Messing, American Bar Association, jmessing@law-on-line.com
> Arshad Noor, individual member, arshad.noor@strongauth.com
> Davi Ottenheimer, individual member, davi@poetry.org
> Ann Terwilliger, Visa International, aterwil@visa.com
> 
> g. TC Convener:
> 
> Arshad Noor, arshad.noor@strongauth.com
> 
> END DRAFT
> 
> 

--
<Put email footer here>