[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [kmip] TTLV encoding concern
Greetings In the discussion that follows, I am advocating for (a) clarification of KMIP specification in regard to TTLV encoding and unused Object Tag allocations, or (b) support for an abbreviated encoding of Attributes. I have been reviewing KMIP vendors’ websites, the KMIP Specification 1.1 and related documents such as KMIP Use Cases 1.0, and I am confused by what seems to be a commonly accepted misapplication of TTLV formatting. Specifically, I do not understand why well-known attributes such as Cryptographic Usage Mask are encoded with a generic Attribute object tag [i.e. Object Tag=420008 (Attribute)] rather than with the object tag that the specification expressly allocates to that attribute [e.g. Object Tag=42002C (Cryptographic Usage Mask)]. A prime example [see below] of the misapplication – repeated in various documents – appears in KMIP Use Cases 1.0: 3.1.1 Use-case: Create / Destroy In this use-case the client issues a Create request, whereby the server creates a new symmetric key and returns the Unique Identifier. To clean up, the client then performs a Destroy operation to destroy the key. Request/Response messages Create (symmetric key) In: objectType=’00000002’ (Symmetric Key), attributes={ CryptographicAlgorithm=’00000003’ (AES), CryptographicLength=’128’, CryptographicUsageMask=‘0000000C’ } Tag: Request Message (0x420078), Type: Structure (0x01), Data: Tag: Request Header (0x420077), Type: Structure (0x01), Data: Tag: Protocol Version (0x420069), Type: Structure (0x01), Data: Tag: Protocol Version Major (0x42006A), Type: Integer (0x02), Data: 0x00000001 (1) Tag: Protocol Version Minor (0x42006B), Type: Integer (0x02), Data: 0x00000000 (0) Tag: Batch Count (0x42000D), Type: Integer (0x02), Data: 0x00000001 (1) Tag: Batch Item (0x42000F), Type: Structure (0x01), Data: Tag: Operation (0x42005C), Type: Enumeration (0x05), Data: 0x00000001 (Create) Tag: Request Payload (0x420079), Type: Structure (0x01), Data: Tag: Object Type (0x420057), Type: Enumeration (0x05), Data: 0x00000002 (Symmetric Key) Tag: Template-Attribute (0x420091), Type: Structure (0x01), Data: Tag: Attribute (0x420008), Type: Structure (0x01), Data: Tag: Attribute Name (0x42000A), Type: Text String (0x07), Data: Cryptographic Algorithm Tag: Attribute Value (0x42000B), Type: Enumeration (0x05), Data: 0x00000003 (AES) Tag: Attribute (0x420008), Type: Structure (0x01), Data: Tag: Attribute Name (0x42000A), Type: Text String (0x07), Data: Cryptographic Length Tag: Attribute Value (0x42000B), Type: Integer (0x02), Data: 0x00000080 (128) Tag: Attribute (0x420008), Type: Structure (0x01), Data: Tag: Attribute Name (0x42000A), Type: Text String (0x07), Data: Cryptographic Usage Mask Tag: Attribute Value (0x42000B), Type: Integer (0x02), Data: 0x0000000C (Encrypt, Decrypt) O O O I am not sure whether the above practice is patently incorrect, or merely inefficient – inefficient because the server must identify an attribute by string comparison [of Attribute Names] rather than by integer comparison [of Object Tags]. Moreover, one of the advantages of a binary protocol – compactness – is diminished by the unnecessary text. The KMIP specification is ambiguous. The introduction to Section 2.1.1 Attribute states that “An Attribute object is a structure …”, but in Section 3 Attributes the individual attribute descriptions assign a variety of types including Structure, Text String, Enumeration, integer, Interval, and Date-Time. To agree with Section 2.1.1, all attributes would have Structure type. [I have not failed to notice the presence of the Attribute Index field; I address that later.] I believe that the above request should be encoded as follows: Tag: Request Message (0x420078), Type: Structure (0x01), Data: Tag: Request Header (0x420077), Type: Structure (0x01), Data: Tag: Protocol Version (0x420069), Type: Structure (0x01), Data: Tag: Protocol Version Major (0x42006A), Type: Integer (0x02), Data: 0x00000001 (1) Tag: Protocol Version Minor (0x42006B), Type: Integer (0x02), Data: 0x00000000 (0) Tag: Batch Count (0x42000D), Type: Integer (0x02), Data: 0x00000001 (1) Tag: Batch Item (0x42000F), Type: Structure (0x01), Data: Tag: Operation (0x42005C), Type: Enumeration (0x05), Data: 0x00000001 (Create) Tag: Request Payload (0x420079), Type: Structure (0x01), Data: Tag: Object Type (0x420057), Type: Enumeration (0x05), Data: 0x00000002 (Symmetric Key) Tag: Template-Attribute (0x420091), Type: Structure (0x01), Data: Tag: Cryptographic Algorithm (0x420028), Type: Enumeration (0x05), Data: 0x00000003 (AES)
Tag: Cryptographic Length (0x42002A), Type: Integer (0x02), Data: 0x00000080 (128)
Tag: Cryptographic Usage Mask (0x420002C), Type: Integer (0x02), Data: 0x0000000C (Encrypt, Decrypt)
The vast majority of attributes defined by the KMIP specification are of single-instance type. In the case that a multi-instance attribute requires disambiguation, the Attribute Index can be specified in a structure. For example, the Name attribute may have multiple instances: Tag: Name (0x420053), Type: Structure (0x01), Data: Tag: Attribute Index (0x420009), Type: Integer (0x07), Data: 0x00000003 Tag: Attribute Value (0x42000B), Type: Text String (0x07), Data: Key of C And if that same attribute had the default Attribute Instance value of 0 (zero), then the above could be reduced to: Tag: Name (0x420053), Type: Text String (0x07), Data: Key of C Allowance of both structured and non-structured Attribute encoding would require only minor change to Section 2.1.1: 2.1.1 Attribute
An Attribute object may appear in both client requests and server responses. An Attribute’s encoding varies, depending on the particular Attribute, but SHALL be a structure [see Table 2] when specifying the objects other than just Attribute Value [i.e. Attribute Index; Attribute Name]. As a special case, the Custom Attribute [see 3.39] must always be a structure as it must always specify its associated Attribute Name. The Attribute Name is a text-string that is used to identify the attribute. The Attribute Index is an index number assigned by the key management server. The Attribute Index is used to identify the particular instance. Attribute Indices SHALL start with 0. The Attribute Index of an attribute SHALL NOT change when other instances are added or deleted. Single-instance Attributes (attributes which an object MAY only have at most one instance thereof) SHALL have an Attribute Index of 0. The Attribute Value is either a primitive data type or structured object, depending on the attribute. When an Attribute structure is used to specify or return a particular instance of an Attribute and the Attribute Index is not specified it SHALL be assumed to be 0. Table 2: Attribute Object Encoding
As stated above, I believe that 3.39 Custom Attribute is the only attribute that ever requires the Attribute Name (42000A) tag, because only the Attribute Name distinguishes one Custom Attribute from another. Regards, … Dave The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]