KMIP Vendor Extension Management KMIP supports ‘extensions’ but provides no mechanism for coordination of values between clients and servers or between vendors – Items – starting with 0x54 rather than 0x42 – Enumerations – using 0x8XXXXXXX (except for Masks which are different) – Message Extension Tim Hudson – 1

KMIP Vendor Extension Management A Vendor extension can be added as: i.Attribute with Name and simple Item Type e.g. the x-AttributeName ii.Attribute with Name and Structure containing items of simple Item Type iii.Re-purposing existing KMIP Object e.g. Adding new enumeration into CREDENTIALS and interpreting the value field differently iv.Using Message Extension Tim Hudson – 2

KMIP Vendor Extension Management Objectives a)Client can determine if server supports a given vendor extension b)Server can display meaningful values for vendor extensions c)Extensions from multiple vendors should not clash i.e. Universal clients and universal servers should be technically possible to produce. Tim Hudson – 3

KMIP Vendor Extension Management TTLV encoding provides a mechanism for meaningful communication of structured information. Vendor extensions should not degenerate into (unmanageable) opaque blobs. Different contexts of usage will require different information to be passed between client and server. Vendor extensions should not degenerate into requiring point-to-point testing against each server. Tim Hudson – 4

KMIP Vendor Extension Management Attributes are queried by Name but encoded by Tag Value – the mapping needs to be known Tag Values selected by Vendors need to not clash Tim Hudson – 5

KMIP Vendor Extension Management Solutions - Summary 1.Require registration of vendor extensions 2.Allow allocation of ranges for extensions to vendors 3.Separate extension range into “private” and “public” extensions 4.Extend QUERY operation to provide more server behaviour details 5.Add new OPERATION to return ‘schema’ information Tim Hudson – 6

KMIP Vendor Extension Management Solutions 1.Require registration of vendor extensions Would prevent clashing usage of Tag Values KMIP TC handles initial registry of values Single registry or separate documents per vendor Include in profile documents 2.Allow allocation of ranges for extensions to vendors Would prevent clashing usage of Tag Values Does not allow for interoperability – still requires vendor- to-vendor coordination Tim Hudson – 7

KMIP Vendor Extension Management Solutions 3.Separate extension range into “private” and “public” extensions Make it clear when extensions are not meant to be interoperable 4.Extend QUERY operation to provide more server behaviour details Return list of supported vendor extensions Return mapping from Name to Tag Value Return implementation limits such as maximum length of byte- arrays and text strings, maximum number of attribute instances for multi-instance attributes, etc Can be handled as additional QUERY_FUNCTION values and fits within existing 1.0 handling. Tim Hudson – 8

KMIP Vendor Extension Management Solutions 5.Add new OPERATION to return ‘schema’ information Requires definition of what a ‘schema’ contains Not a simple solution Potential v2.0 or later item Tim Hudson – 9

KMIP Vendor Extension Management Other items 6.Need to define what “uniquely identifies the vendor” means DNS name? URI? Vendor Identification in QUERY response payload (SPEC 4.24, line 1419) Vendor Identification in MESSAGE_EXTENSION payload (SPEC 6.16, line 1637) 7.Need to add new Use Cases to match current or proposed vendor usage Tim Hudson – 10

KMIP Vendor Extension Management Recommended Solution – KMIP TC maintains registry of vendor extensions – QUERY operation extended to support returning list of extensions supported (including Tag Value to Attribute Name mapping) – Define Vendor Identification as a URI – Add use cases to match current vendor usage Tim Hudson – 11