Common Identifiers Providing Globally Unique Identifiers for UUID and Application IDs of keys and other objects

2 UUID and Application ID Defined as Text Strings UUID is set by Server Application ID is set by Client If not set by client can be defined by server No definition for how they are formed No minimum No maximum No restrictions other than Text String Binary Coded HexHex? POSIX Characters? How do You Find Objects if They are not on Local Server? Which is easier to find? Waldo km://lookherefirst.org/0/Sol/3/Switzerland/Zurich/BobGsPlace/Waldo What if there is more than one Waldo? How many Bobs are there? How many

3 Globally Unique Common Identifier Formatting Existing Well Known Identifiers Domain Everyone has them - unique Internet name Customers can create sub-domains to suit their needs Establish a zone of KMS Administrative Authority (realm) Directory Able to separate conflicting key ID namespaces Customers can organize their key space to suit their needs Applications can build a hierarchy to meet requirements Hierarchies are a well understood concept (e.g. file trees) Current ID Formats Can be any value API can convert ID to the encoding required by the protocol

4 Defining a Common Format for Identifiers using Profiles Globally Unique Common Scheme (e.g. URI) km:// May want to define a full IETF URI scheme Using RFC 1034 and RFC 1035 Domain Naming Convention Traditional Domains: example.com Sub-domain Support: traders.bigbank.com and analyst.bigbank.com Object Type /0 = key, /1 = certificate, /2 = policy, /3 = group, /4 = ???, etc… Providing additional Separation using Directories /Sol/3/Switzerland/Zurich/BobGsPlace/ Starts with / ends with / Identifier Waldo Text, Hex, Binary, etc… All current naming schemes should be supportable under a common format Using Profiles Allows for more than One Naming Convention

5 Additional Considerations Setting Limits to Create Common Formats Size & Scope Minimum and maximum lengths Short and Long forms of an identifier Text representation (POSIX Characters, Hex Characters, etc…) km://example.com/0/group/dir2/dir3/ km://domhash/0/0/1/2/3/4/5/6/ ABCDEF km://analyst.bigbank.com/1/CertCommonName km://example.com/2/group1/AZ-az-09.POSIX-Character-Identifier-policy Backwards Compatibility Client should only be required to know Identifier while using symbolic links or search filters for externally stored keys (Todays identifiers can be mapped into a larger naming convention 0123 = km://example.org/0/0123 Using Symbolic Links or preferred domain search Still requires access control which is not part of the naming scheme but the identifier scheme can be used for access control though!

KMIP Profiles Creating Requirements Guidelines for Creating Profiles

7 KMIP Profiles Purpose is to define what any implementation of the specification must adhere to in order to claim conformance Define the use of KMIP objects, attributes, operations, message elements and authentication methods within specific contexts of KMIP server and client interaction Define a set of normative constraints for employing KMIP within a particular environment or context of use Optionally, require the use of specific KMIP functionality or in other respects define the processing rules to be followed by profile actors (e.g. Server & Client) Defined OASIS Profiles Profiles are further qualified by an authentication suite TLS V1.0 / V1.1 / V1.2 or similar External Profile in development – (Not OASIS developed) INCITS T10 profile – Fibre Channel Security Protocol v2.0 (FCSP2)

8 Defining a Full Profile for Real World Use Server requirements (required) Includes all objects, operations and attributes that a client can access Defined down to all required components of those objects, operations and attributes Even if optional in KMIP specification, it can be required in a profile Definition of any extensions and how they are to be used Client requirements (optional) What are the bare minimum requirements for a Client to claim conformance e.g. Must support get of a symmetric key using unique identifier Can be a single statement Basically states that support of any operation, object and attributes that are supported by the server and you can be conformant Protocol requirements (recommended) Wire protocol KMIP messaging uses (e.g. SSL 3.0, TLS v1.2, FCSP, etc…) Authentication requirements (recommended) Certificates, user ID/password, mutual authentication, DH-CHAP, etc… Interoperability Requirements (recommended) How to prove conformance either as part of the profile or as a separate Test Case guide Use Cases (recommended) How objects, operations and attributes are to be used with message examples