RE: [members] Proposed Charter for OASIS Key Management Interoperability Protocol (KMIP) TC

["Martin Chapman" <martin.chapman@oracle.com>]

As part of my duty as a TAB member, I was asked to review this charter.
In my view the charter provides the necessary information required by the OASIS TC Process.

The only comment I have is to request that the acronym "TPM" under the scope section be defined.

Cheers,
 Martin.

> -----Original Message-----
> From: Mary McRae [mailto:marypmcrae@gmail.com] On Behalf Of Mary McRae
> Sent: 12 February 2009 14:33
> To: members@lists.oasis-open.org; tc-announce@lists.oasis-open.org
> Cc: oasis-charter-discuss@lists.oasis-open.org
> Subject: [members] Proposed Charter for OASIS Key Management Interoperability Protocol (KMIP) TC
> 
> To OASIS Members:
> 
>   A draft TC charter has been submitted to establish the OASIS Key
> Management Interoperability Protocol (KMIP) Technical Committee (below). In
> accordance with the OASIS TC Process Policy section 2.2:
> (http://www.oasis-open.org/committees/process-2008-06-19.php#formation) the
> proposed charter is hereby submitted for comment. The comment period shall
> remain open until 11:45 pm ET on 26 February 2009.
> 
>   OASIS maintains a mailing list for the purpose of submitting comments on
> proposed charters. Any OASIS member may post to this list by sending email
> to:
> mailto: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 emails must join the group by selecting "join group" on the
> group 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 within four days of
> the close of the comment period. The announcement and call-in information
> will be noted on the OASIS Charter Discuss Group Calendar.
> 
>   We encourage member comment and ask that you note the name of the proposed
> TC ([KMIP]) in the subject line of your email message.
> 
> Regards,
> 
> Mary
> 
> ---------------------------------------------------
> Mary P McRae
> Director, Technical Committee Administration
> OASIS: Advancing open standards for the information society
> email: mary.mcrae@oasis-open.org
> web: www.oasis-open.org
> phone: 1.603.232.9090
> 
> ===========
> PROPOSED CHARTER FOR REVIEW AND COMMENT
> 
> Proposed Charter for OASIS Key Management Interoperability Protocol (KMIP)
> Technical Committee
> 
> 
> The name of the TC:
> Key Management Interoperability Protocol (KMIP) Technical Committee
> 
> 
> Statement of purpose:
> The KMIP Technical Committee will develop specification(s) for the
> interoperability of key management services with key management clients. The
> specifications will address anticipated customer requirements for key
> lifecycle management (generation, refresh, distribution, tracking of use,
> life-cycle policies including states, archive, and destruction), key
> sharing, and long-term availability of cryptographic objects of all types
> (public/private keys and certificates, symmetric keys, and other forms of
> "shared secrets") and related areas.
> 
> 
> Scope:
> The initial goal is to define an interoperable protocol for standard
> communication between key management servers, and clients and other actors
> which can utilize these keys. Secure key management for TPMs and Storage
> Devices will be addressed. The scope of the keys addressed is
> enterprise-wide, including a wide range of actors: that is, machine,
> software, or human participants exercising the protocol within the
> framework. Actors for KMIP may include:
> * Storage Devices
> * Networking Devices
> * Personal devices with embedded storage (e.g. Personal Computers, Handheld
> Computers, Cell Phones)
> * Users
> * Applications
> * Databases
> * Operating Systems
> * Input/Output Subsystems
> * Management Frameworks
> * Key Management Systems
> * Agents
> 
> Out of scope areas include:
> * Implementation specific internals of prototypes and products
> * Multi-vendor Key Management facility mirrors or clusters
> * Definition of an architectural design for a central enterprise key
> management or certificate management system other than any necessary models,
> interfaces and protocols strictly required to support interoperability
> between Actors in the multi-vendor certificate and key management framework.
> * Framework interfaces not dedicated to secure key and certificate
> management
> * Certain areas of functionality related to key management are also outside
> the scope of this technical committee, in particular registration of
> clients, server-to-server communication and key migration.
> * Bindings other than tag-length-value wire protocol and XSD-based
> encodings.
> 
> List of deliverables:
> The deliverables for the KMIP Technical Committee are anticipated to include
> the following:
> * Revised KMIP Specification v0.98. This provides the normative expression
> of the protocol, including objects, attributes, operations and other
> elements. A Committee Specification is scheduled for completion within 12
> months of the first TC meeting.
> * Revised KMIP Usage Guide v0.98. This provides illustrative and explanatory
> information on implementing the protocol, including authentication profiles,
> implementation recommendations, conformance guidelines and security
> considerations. A Committee Specification is scheduled for completion within
> 12 months of the first TC meeting.
> * Revised KMIP Use Cases and Test Cases v0.98. This provides sample use
> cases for KMIP, test cases for implementing those use cases, and examples of
> the protocol implementing those test cases. A Committee Specification is
> scheduled for completion within 12 months of the first TC meeting.
> * Revised KMIP Frequently Asked Questions. This document provides guidance
> on what KMIP is, the problems it is intended to address and other frequently
> asked questions.
> 
> KMIP, as defined in the above deliverables, will be scoped to include the
> following:
> 1) Comprehensive Key and Certificate Lifecycle Management Framework
>   A. Lifecycle Management Framework to Include:
>     a) Provisioning of Keys and Certificates
>        i) Creation
>       ii) Distribution
>      iii) Exchange/Interchange
>       iv) Auditing
>     b) Reporting
>     c) Logging (Usage tracking)
>     d) Backup
>     e) Restore
>     f) Archive
>     g) Update/Refresh
>     h) Management of trust mechanisms between EKCLM actors only as necessary
> to support EKCLM
>   B. Comprehensive Key and Certificate Policy Framework to include:
>     a) Creation
>     b) Distribution
>     c) Exchange/Interchange
>     d) Auditing
>     e) Reporting
>     f) Logging (Usage tracking)
>     g) Backup
>     h) Restore
>     i) Archive
>     j) Update/Refresh
>     k) Expectation of Policy Enforcement
>        i) At endpoints
>       ii) At Key Manager
>      iii) At intermediaries between endpoints and Key Manager facility
>   C. Interoperability between Machine Actors in performing all aspects of A)
> and B), and addressing:
>     a) pre-provisioning and late binding of keys and certificates
>     b) support for hierarchical or delegation or direct models
>     c) actor discovery and enrollment as necessary to support ECKLM
>     d) key, certificate and policy migration
>     e) audit and logging facilities
>   D. General Capabilities may include:
>     a) Secure and Robust Mechanisms, Techniques, Protocols and Algorithms
>     b) Recovery capabilities, only as needed by interoperable interfaces,
> anticipating power failure, or other common failures of automated Actors
>     c) Forward compatibility considerations
>     d) Interface to Identity Management facilities as necessary for A) and
> B)
>     e) Interface to Enterprise Directory facilities as necessary for A) and
> B)
> 
> KMIP TC will also support activities to encourage adoption of KMIP. This
> would likely include:
> Interoperability sessions to test effectiveness of the specification
> Reference implementations of KMIP functionality
> 
> IPR Mode under which the TC will operate:
> The KMIP TC is anticipated to operate under RF on RAND.
> 
> 
> Anticipated audience or users:
> KMIP is intended for the following audiences:
> 
> * Architects, designers and implementers of providers and consumers of
> enterprise key management services.
> 
> Language:
> Work group business and proceedings will be conducted in English.
> 
> 
> Non-normative information
> 
> Identification of similar or applicable work:
> Similar work is currently underway in several other organizations:
> * OASIS EKMI TC. We see KMIP TC as addressing a broader scope than the
> primarily symmetric key focused EKMI, providing a more comprehensive
> protocol in which SKSML can potentially participate.
> * IEEE P1619.3. We see KMIP TC as addressing a broad scope than the
> primarily storage-related P1619.3.
> * TCG Infrastructure Working Group. We see KMIP TC as addressing a broader
> scope than the primarily TPM-related TCG IWG.
> * IETF Keyprov. We see KMIP TC as addressing a broader scope than the
> primarily mobile-related IETF Keyprov.
> 
> Date, time, and location of the first meeting:
> The intended date for the first meeting is April 24th 2009, to be held as a
> Face to Face meeting in San Francisco in conjunction with the RSA
> Conference. Exact location and logistics TBD
> 
> Projected on-going meeting :
> Conference calls will be held weekly, to be sponsored by one or more of the
> companies proposing the KMIP TC. These conference calls will be complemented
> by the following:
> * Face to face meetings as determined by the KMIP TC.
> * General communication will be via email reflectors with archiving provided
> by the KMIP TC.
> * KMIP TC progress will be communicated via a KMIP TC web page.
> * The KMIP TC will communicate (conference calls, joint working sessions,
> etc.) with external groups as appropriate.
> * The KMIP TC will communicate (conference calls, joint working sessions
> etc.) with internal OASIS groups (other TCs) as appropriate.
> 
> Names, electronic mail addresses, and membership affiliations of at least
> Minimum Membership:
> Bob Griffin, EMC/RSA, Robert.griffin@rsa.com
> Robert Philpott, EMC/RSA, Robert.philpott@rsa.com
> Mark Schiller, HP, mark.schiller@hp.com
> Jishnu Mukerji, HP, jishnu@hp.com
> Anthony Nadalin, IBM, drsecure@us.ibm.com
> Robert Haas, IBM, nih@zurich.ibm.com
> Walt Hubis, LSI, walt.hubis@lsi.com
> Jon Geater, Thales, jon@nciper.com
> Marcus Streets, Thales, marcus.streets@thales-esecurity.com
> Martin Skagen, Brocade, mskagen@brocade.com
> Karla Thomas, Brocade, karlat@brocade.com
> Subhash Sankuratripati, NetApp, Subhash@netapp.com
> Paolo Bezoari, NetApp, Bezoari@netapp.com
> Dave B Anderson, Seagate, dave.b.anderson@seagate.com
> 
> 
> The name of the Convener who must be an Eligible Person:
> Robert Griffin (EMC)
> 
> 
> The name of the Member Section with which the TC intends to affiliate, if
> any.
> None.
> 
> List of contributions of existing technical work that the proposers
> anticipate will be made to this TC:
> * KMIP Specification v0.98
> http://xml.coverpages.org/KMIP/KMIP-v0.98-final.pdf
> * KMIP Usage Guide v0.98
> http://xml.coverpages.org/KMIP/KMIP-UsageGuide-v0.98-final.pdf
> * KMIP Use Cases and Test Cases v0.98
> http://xml.coverpages.org/KMIP/KMIP-UseCases-v0.98-final.pdf
> * KMIP FAQ
> http://xml.coverpages.org/KMIP/KMIP-FAQ.pdf
> 
> 
> Frequently Asked Questions (FAQ) document:
> TBD
> 
> 
> Proposed working title and acronym for the specification(s) to be developed
> by the TC.
> * KMIP Specification
> * KMIP Usage Guide
> * KMIP Use Cases and Test Cases
> * KMIP FAQ
> 
> 
> 
> ---------------------------------------------------------------------
> 
> This email list is used solely by OASIS for official consortium communications.
> 
> Opt-out requests may be sent to member-services@oasis-open.org, however, all members are strongly
> encouraged to maintain a subscription to this list.