Fw: [oasis-charter-discuss] EKMI Pre-Launch Teleconference

After reading the charter, and reading the related information the charter pointed (StongAuth SKML description from here: http://www.strongkey.org/resources/documentation/misc/skcl-sks-protocol.html)  to I have the following general comments:

This thing looks to me like it is addressing only a VERY SMALL subset of what is needed.  It looks to me like what is there right now covers ONLY the case of requesting retrieval (i.e. "List"/"read" operation) of a symmetric key.  This one seems like the relatively EASY one to solve.  The others ( add/modify/delete/query ) will require much more work and don't seemed to covered in the related material or in the charter

It is good to see that StrongAuth has shown examples of using "SOAP bindings" but stopped short, as protocols like WS-Trust already handle symmetric and asymmetric keys and provide for a better transport. For Key management/administration though, I think there is quite a bit more that needs to be defined that is not covered in the  related material or in the charter. There is no real in/out of scope items for this TC which makes me think that the will be far too much uncertainty.

There is other standards work in this space and there is no clear relationship called out in the charter.

Specific Charter comments marked <ajn>:

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.  

<ajn> Also, it seems that the use of PKI for SSL/TLS communications link protection is the most 

common usage (to protect various protocols - HTTP, LDAP - and to implement VPN with 

SSL-based VPN solutions). </ajn>

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.

<ajn> While companies are "using PKI", they are not, in wide usage, deploying their own PKI - rather 

they are procuring certificates from that subset of CAs (PKIs) that are held within browser

default trusted signers lists.  Other usages are "hidden"/"buried" inside products.  The current 

situation, IMO, with public/private keys is that companies don't know how fragmented

 their usage really is. </ajn>

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,

<ajn> XKMS?  </ajn>etc.

<ajn> (also, the protocols/formats listed here seem tied to CA/RA <-> Entity communication - not the

management of keys/certs distributed across a variety of key storage media within an organization.

This latter problem still requires attention.) </ajn>

-- 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. 

<ajn> similar problems exist for both symmetric and asymmetric key management. </ajn>

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

<ajn> 0) TC will publish a Note defining the "space" for these protocols, as distinct from existing work

    in areas of CA/RA <-> Entity communications </ajn>

A) The TC will define the request/response protocols for: 

1. Requesting a new or existing symmetric key <ajn> (why just symmetric?)  </ajn> from a server;

2. Requesting policy information from a server related to caching of

keys on the client;

3. Sending a symmetric key <ajn> (why just symmetric?) </ajn> 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.

   <ajn>  What about sending keys TO the server?

     Query of keys (and/or information about such keys) in a server?

     Add/Generate/Modify/Delete/List/Query of key(s) </ajn>

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);

</ajn> Is this a compliance suite ? </ajn>

C) The TC will provide guidance on how a symmetric (and asymmetric) key-management

(key management as distinct from CA/RA <-> Entity communications).

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;

</ajn> You have lost me here </ajn>

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)

</ajn> Based upon what I have seen in the related material this is a far too aggressive 

schedule </ajn>

Anticipated Audiences:

Any company or organization that has a need for managing

cryptographic keys <ajn> which are used </ajn> across applications, databases, operating systems 

and devices, yet desires centralized policy-driven management of all

cryptographic keys <ajn> (and multiple copies of such keys) </ajn> 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.  <ajn> Also coordinate with WS-SX TC. </ajn>

<ajn> Coordination with other standards bodies' efforts - known work underway or existing:

 - TCG ESSG subgroup of Storage WG

 - IETF Keyprov BOF

 - W3C existing XKMS work </ajn>

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.  <ajn> (See above - there is other work underway) </ajn>  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, 

June Leung, FundSERV,  

John Messing, American Bar Association, 

Arshad Noor, individual member,  

Davi Ottenheimer, individual member, 

Ann Terwilliger, Visa International, 

g. TC Convener:

Arshad Noor, 

END DRAFT

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122