1. KMIP Profiles version 1.3 A Method to Define Operations Access Control and Interaction Between a Client and Server Presented by: Kiran Kumar Thota & Bob Lockhart

2. Defining the Problem A user wants to create and control the lifecycle of a key via an application that is responsible for the data being protected Primary use cases are for applications that manage data lifecycle A client needs to get the key to access the data but CANNOT create or control the key Data is encrypted or decrypted at its point of use and thus protected when in flight or at rest. If defined properly, profiles could be created to support any version of the KMIP specification (e.g. 1.0, 1.1, 1.2, etc…) Use the KMIP Profiles 1.3 document to define how it is done This keeps client development requirements lower Puts more work on server vendors (potentially)

3. Solving the Problem – Step 1 To date profiles have only defined object types and attributes There is no reason not to allow it to also define operations Limit the operations performed by a given client profile “Administrative” users could perform some or all operations with the exception of get key “Managed” users could perform get and other allowed operations NOTE:Defining two or more client types within one profile should be allowed to avoid confusion between different profiles

4. Example Different Clients in a Profile Administrative Client Operations Create Create Key Pair Register Re-Key Re-Key Key Pair Derive Key Certify Re-certify Locate Check Get Attributes Get Attribute List Managed Client Operations Locate Check Get Get Attributes Get Attribute List Add Attribute Modify Attribute Delete Attribute Activate Revoke Destroy Archive Recover Validate Query Discovery Versions Cancel Modify Attribute Obtain Lease Get Usage Allocation Validate Query Discovery Versions

5. Considerations What ifs… What if an “administrative” client needs to access a different set of keys? What if a managed client needs to fit into two profiles What if … There are a lot of different use cases but until someone finds one, these are vendor specific implementations we should stay away from We need to be flexible enough to allow server and client vendors to determine how best to differentiate themselves We need to stay just enough ahead of the market when defining how KMIP works This will require additional considerations for test cases by requiring two different clients or sets of credentials We haven’t really done this one before Focus on the messaging via Profiles in 1.x, tackle the tough stuff in 2.x and later