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 – tjh@cryptsoft.com
1
KMIP Vendor Extension
Management
- A Vendor extension can be
added as:
- Attribute with Name and
simple Item Type
- Attribute with Name and
Structure containing items of simple Item Type
- Re-purposing existing KMIP
Object
- e.g. Adding new enumeration
into CREDENTIALS and interpreting the value field differently
- Using Message Extension
Tim Hudson – tjh@cryptsoft.com
2
KMIP Vendor Extension
Management
- Objectives
- Client can determine if
server supports a given vendor extension
- Server can display meaningful
values for vendor extensions
- Extensions from multiple
vendors should not clash
Tim Hudson – tjh@cryptsoft.com
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 – tjh@cryptsoft.com
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 – tjh@cryptsoft.com
5
KMIP Vendor Extension
Management
- Solutions - Summary
- Require registration of
vendor extensions
- Allow allocation of ranges
for extensions to vendors
- Separate extension range
into ��private�� and ��public�� extensions
- Extend QUERY operation to
provide more server behaviour details
- Add new OPERATION to return ��schema�� information
Tim Hudson – tjh@cryptsoft.com
6
KMIP Vendor Extension
Management
- Solutions
- 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
- 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 – tjh@cryptsoft.com
7
KMIP Vendor Extension
Management
- Solutions
- Separate extension range
into ��private�� and ��public�� extensions
- Make it clear when extensions
are not meant to be interoperable
- 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
Tim Hudson – tjh@cryptsoft.com
8
KMIP Vendor Extension
Management
- Solutions
- 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 – tjh@cryptsoft.com
9
KMIP Vendor Extension
Management
- Other items
- Need to define what ��uniquely
identifies the vendor�� means
Vendor Identification in QUERY
response payload (SPEC 4.24, line
1419)
Vendor Identification in MESSAGE_EXTENSION
payload (SPEC 6.16, line 1637)
- Need to add new Use Cases
- to match current or proposed
vendor usage
Tim Hudson – tjh@cryptsoft.com
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 – tjh@cryptsoft.com
11
