KMIP Use Cases

Update on the process

Agenda

• Goals• Process Flow, Atomics, Batch, Composites, and

Not KMIP• Evaluating the Document in light of the Goals• Next Steps• Example Process Flows

Goals

• Create a cookbook of applied KMIP operations • Demonstrate how the specification today can

be applied.• Make the document readable to

non-OASIS/non KMIP-TC readers• Demonstrate Specification Maturity

Process Flow, Managed Objects, Atomics, Batch, Composites, and Not KMIP

• Process Flow – straight from the Use Case document – what are the steps to perform a use case.

• Managed Objects – given a process flow, what KMIP Managed Objects can be applied to the process

• Atomics – Singular KMIP operations that can be applied to a process step (or components of batch or composite operations)

• Batch Operations – singular operations in serial as per the specification• Composite Operations – A series of KMIP Atomic operations that require Server or

Client processing that notes state or other applied logic to a given operation.– Composite operations note that vendor interpretation is required to implement – This is a point that denotes that Vendors can provide value in their unique implementations

• Not KMIP – a Process Flow Step that is best implemented outside the specification. – There is nothing wrong with KMIP not doing everything.– Brief reminder of one of the 12 truths – “In protocol design, perfection has been reached not when

there is nothing left to add, but when there is nothing left to take away” (IETF RFC 1925).

Evaluating the DocumentIn light of the goals….

• Patterns of utilization– When applying atomic, batch, and composite KMIP commands patterns of use start to become

self evident– This is a good thing.

• Process Flow– Means of evaluating what operations and managed objects can be applied

• Many use cases were removed because they were not directly associated with the specification as it stands. – Specifically Policy Use Cases – Policy is a very good thing, but until the TC comes to terms on

what it looks like there is no value adding it to a use case. • Worth noting that a number of use cases were incomplete – information was not

formatted within the prescribed format in the document or there was no information at all

• For those use cases that has applicable process flows and were complete, we evaluated the use case for Managed Objects, Atomic, Batch, Composite, and Not KMIP operations.

• This is the previously mentioned chainsaw.

Next Steps

• Build out applicable use cases that were not formatted correctly and apply Managed Objects, Atomics, Batch, Composite and Not KMIP Operations.

• Add some new Use Cases – focus on KMIP 1.3 operations as well as new fields of use like communications

• Attempt to define use cases for each class of operation• Revise the prescribed format to make the Use Cases

document more readable by non TC members

Example Process Flows9.1 Use case KSTUC-1: Storage Device Requests Key from KMS• Managed Objects:

– Symmetric Key• Process Flow

– Storage device requests key creation (Not KMIP)• Storage device sends key creation request to KMC component. (Not KMIP)• KMC component in enterprise securely sends a request to KMS component. (Batch: KMIP Create, KMIP Get)

– Storage device receives response from system (Batch Response: KMIP Create, KMIP Get)• KMS creates key and response message and securely sends message to KMC component. (Batch Response: KMIP Create, KMIP Get)• KMC component sends response to storage device component (Not KMIP)

5.2 Use Case HM-2: Local Key Foundry with Key Wrapping• Managed Objects:

– Certificate, Symmetric Key, PGP Key, Public Key, Private Key, Secret Object, Opaque Object. • Process Flow

– Xerxes logs into KMS. (Not KMIP)– Xerxes lists all Object Identifiers known to KMS, which includes all keys residing on HSMs in the enterprise. (KMIP Locate)– Xerxes creates an AES-256 symmetric key on KMS using KMS HSM Management UI, which is subsequently imported to the Partition B

on HSM-1. (KMIP Create, KMIP Get (UUID), KMIP Register)– Xerxes deactivates key KEY1 on KMS; KEY1’s state transition is replicated to Partition C of HSM-2. (KMIP Modify Attribute (State) – Using KMS UI, Xerxes finds all DES keys associated with all registered HSMs and destroys them. All keys are destroyed on

corresponding partitions across all registered HSMs. (KMIP Locate (Cryptographic Algorithm DES), KMIP Destroy)– Xerxes clones the key material from an existing HSM partition (2A) to a new module using KMS UI. (Composite: KMIP Locate, KMIP

Get, KMIP Get Attributes, KMIP Register)