updated draft agenda for KMIP TC F2F (Feb. 23/24, 2012)

[<robert.griffin@rsa.com>]

Proposed agenda for KMIP F2F (February 2012)

 

The primary goal of the face-to-face will be to move forward on enhancements to KMIP that we could reasonably accomplish in a V1.2 release. In that regard, it looks like it would be worthwhile to spend most of Thursday discussing the use cases and requirements that we want to address in V1.2 (including cloud/virtualization, storage, PGP, QKD, HSMs, but also KMIP-specific use cases such as entity administration), identifying implications of those use cases for protocol objects/operations/attributes, for usage guidance, for profiles and for interoperability testing. Then on Friday we would look as much as possible at specific enhancements to address those use cases and requirements, anticipating that some enhancements will address multiple use cases and requirements. We also want to allocate time for discussion of testbeds and of interoperability testing.

 

I’ve included for each topic a suggestion for who could prep for and lead discussion of that topic. Please take a look and if your name is next to a topic, let me know if you ok with that topic.

 

I’ve also included at the end of the email the list of V1.2 topics that I’d sent around last week, by way of context for the agenda.

 

 

Thursday Feb 23, 2012 (all times US Pacific Standard Time)

 

10:30 to 10:45

- welcome, roll call

- review and approval of draft agenda

- review/approval of minutes from preceding meeting(s)

 

10:45 – 11:15

-    Discussion of interoperability testing (Mathias B / Tim H)

-    KMIP testbed (Gordon A.)

 

11:15 to 12 – entity-related use cases (Denis) [These derive from particularly from storage and cloud scenarios]

- migration of keys across servers

- other server to server scenarios

- smart clients, particularly communicating with multiple servers

 

12 to 1 - lunch

 

1 to 2:15 – entity-related use cases, continued (Denis

     - administrative use cases

     - trust establishment across discontinuous secure channels (for example, proxies)

      

2:15 to 2:30 - break

 

2:30 to 4:30 – review use cases / requirements not covered in entity discussion

-    Storage (Gordon A.)

-    Cloud / virtualization (tbd)

-    PGP (Mike A.)

-    QKD (John L.)

-    XML tools (Tim H.)

 

4:30 to 5 - checkpoint/review and wrap-up Day 1

 

5 pm adjourn

 

6 pm dinner

 

 

Friday February 24, 2012

 

8 to 8:15 - welcome, roll call

 

8:15 to 8:30 – review of day 1

- review and revision of agenda

 

8:30 – 10:00 entity (Denis)

- entity object definition (differentiation / delegation)

- entity groups

- entity management (registration)

- URIs as identities

 

10 to 10:15 - break

 

10:15 to 11:45 – policy/permissions/groups

- XACML presentation (Hal)

- access/permission policies (Robert H.)

- cryptographic policies (tbd)

- object groups for policy _expression_ (Krishna)

-

11:45 to 12:00 - checkpoint/review of morning

 

12 to 1 - lunch

 

1:00 to 2:00 – trust establishment approaches (Judy F)

- alternatives to TLS for end-to-end trust with intermediaries

- enhancements to wrapped keys

 

2:00 to 3:00 – PGP-related enhancements (Mike A)

- PGP objects / attributes

- PGP operations

- PGP trust establishment

 

3:00 - 3:15 - break

 

3:15 to 4:00 (KMIP doc editors)

-    Implications of use cases and KMIP enhancements for usage guide, profiles and use cases

 

4:00 to 4:30 – planning, review and wrap-up

 

- V1.2 work items

- V1.2 schedule

 

4:30 pm adjourn

 

 

 

 

From: Griffin, Robert
Sent: Wednesday, January 18, 2012 7:56 PM
To: kmip@lists.oasis-open.org
Subject: KMIP V1.2 topics

 

Hi –

 

For our KMIP TC call tomorrow (including for discussion of the F2F agenda), here’s the list of topics that I know of so far in terms of V1.2 enhancements:

 

Use cases that will drive our enhancements:

 

-          Virtualization-related use cases. Implications of these will likely include entity object, group object, policy object, registration operations.

 

-          Storage-related use cases. Implications here include alternative trust establishment models

 

-          PGP-related use cases. Implications here include new PGP-related objects and operations.

 

-          QKD use cases; implications include alternatives for trust establishment

 

Enhancements to KMIP protocol

 

-          PGP objects, operations and attributes

 

-          Entity, including different entity types, delegation models, entity groups

 

-          Policies, including access/permission policies, cryptographic policies

 

-          Enhancements to registration operation

 

-          Other modifications to groups, particularly for cryptographic objects (as opposed to entities

 

-          alternatives to TLS for end-to-end trust, such as with intermediaries

 

KMIP profiles, conformance validation, etc

 

-          New profiles related to new use cases

 

-          Test-bed and/or certification through SNIA SSIF or UNH

 

These possible enhancements are included in the current version of the V1.1 Usage Guide:

 

·         Registration of Clients. This would allow in-band registration and management of clients, which currently may only be registered and/or managed using off-line mechanisms.

·         Client-requested specification of additional clients that are allowed to use a key. This requires coordinated identities between the client and server, and as such, is deferred until registration of clients is addressed.

·         Registration of Notifications. This would allow clients to specify, using an in-band mechanism, information and events that they wish to be notified of, and what mechanisms should be used for such notifications, possibly including the configuration of pushed cryptographic material. This functionality would assume the Registration of Clients as a prerequisite.

·         Key Migration. This would standardize the migration of keys from one HSM to another, using mechanisms already in the protocol or ones added for this purpose.

·         Server to Server key management. This would extend the protocol to support communication between key management servers in different key management domains, for purposes of exporting and importing cryptographic material and potentially policy information.

·         Multiple derived keys. This would allow the creation of multiple derived keys from one or more input keys. Note, however, that the current version of KMIP provides the capability to derive multiple keys and initialization vectors by creating a Secret Data object and specifying a cryptographic length equal to the total length of the derived objects.

·         XML encoding. _expression_ of KMIP in XML rather than in tag/type/length/value may be considered for the future.

·         Specification of Mask Generation Function. KMIP does not currently allow clients to specify the Mask Generation Function and assumes that encryption or signature schemes, such as OAEP or PSS, use MGF1 with the hash function as specified in the Cryptographic Parameters attribute. Client specification of MGFs may be considered for the future.

·         Server monitoring of client status. This would enable the transfer of information about the client and its cryptographic module to the server. This information would enable the server to generate alarms and/or disallow requests from a client running component versions with known vulnerabilities.

·         Symmetric key pairs. Only a subset of the cryptographic usage bits of the Cryptographic Usage Mask attribute may be permitted for keys distributed to a particular client. KMIP does not currently address how to securely assign and determine the applicable cryptographic usage for a client.

·         Hardware-protected attribute. This attribute would allow clients and servers to determine if a key may only be processed inside a secure cryptographic device, such as an HSM. If this attribute is set, the key may only exist in cleartext within a secure hardware device, and all security-relevant attributes are bound to it in such a way that they may not be modified outside of such a secure device.

·         Alternative profiles for key establishment. Less capable end-clients may not be able to support TLS and should use a proxy to communicate with the key management system. The KMIP protocol does not currently define alternative profiles, nor does it allow end-clients relying on the proxy model to securely establish a key with the server.

·         Attribute mutation. The possibility for the server to use attribute values different than requested by the client if these values are not suitable for the server, and return these values in the response, instead of failing the request.

·         Cryptographic Domain Parameters. KMIP allows a limited number of parameters to be specified during a Create Key Pair operation. Additional parameters may be considered for the future.

·         Certificate Suspension/Unsuspension. KMIP does not currently support certificate suspension (putting a certificate on hold) or unsuspension (removing a certificate from hold).  Adding support for certificate suspension/unsuspension into KMIP may be considered for the future.

·         Namespace registration. Establishing a registry for namespaces may be considered for the future.

·         Registering extensions to KMIP enumerations. Establishing a registry for extensions to defined KMIP enumerations, such as in support of profiles specific to IEEE P1619.3 or other organizations, may be considered for the future.

 

Regards,

Bob