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
1
Tim Hudson – tjh@cryptsoft.com
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
2
Tim Hudson – tjh@cryptsoft.com
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.
3
Tim Hudson – tjh@cryptsoft.com
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.
4
Tim Hudson – tjh@cryptsoft.com
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
5
Tim Hudson – tjh@cryptsoft.com
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
6
Tim Hudson – tjh@cryptsoft.com
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
•
•
7
Would prevent clashing usage of Tag Values
Does not allow for interoperability – still requires vendorto-vendor coordination
Tim Hudson – tjh@cryptsoft.com
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 bytearrays 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.
8
Tim Hudson – tjh@cryptsoft.com
KMIP Vendor Extension Management
• Solutions
5. Add new OPERATION to return ‘schema’
information
•
•
•
9
Requires definition of what a ‘schema’ contains
Not a simple solution
Potential v2.0 or later item
Tim Hudson – tjh@cryptsoft.com
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
•
10
to match current or proposed vendor usage
Tim Hudson – tjh@cryptsoft.com
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
11
Tim Hudson – tjh@cryptsoft.com