1 / 8

Common Identifiers

Common Identifiers. Providing Globally Unique Identifiers for UUID and Application ID’s of keys and other objects. 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

damon-parrish
Télécharger la présentation

Common Identifiers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Common Identifiers Providing Globally Unique Identifiers for UUID and Application ID’s 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 Bob’s 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/01001001010010010010010001 • km://domhash/0/0/1/2/3/4/5/6/0123456789ABCDEF • 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 (Today’s 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!

  6. 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

More Related