OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [kmip] TTLV encoding concern


I thought that the idea of using string names for attributes allows the use of 
X- and Y- attribute name extensions that you could not do with a fixed set of codes. 


Mark Joseph, PhD
President
P6R, Inc
408-205-0361
www.p6r.com



<div>-------- Original message --------</div><div>From: "Featherstone, David" <David.Featherstone@safenet-inc.com> </div><div>Date:06/27/2014  2:39 PM  (GMT-08:00) </div><div>To: kmip@lists.oasis-open.org </div><div>Subject: [kmip] TTLV encoding concern </div><div>
</div>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<http://docs.oasis-open.org/kmip/spec/v1.1/os/kmip-spec-v1.1-os.html#_Toc333494584> and related documents such as KMIP Use Cases 1.0<http://docs.oasis-open.org/kmip/usecases/v1.0/cs01/kmip-usecases-1.0-cs-01.html#_Toc262822053>, 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<http://docs.oasis-open.org/kmip/usecases/v1.0/cs01/kmip-usecases-1.0-cs-01.html#_Toc262822053>:

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: Attribute Name (0x42000A), Type: Text String (0x07), Data: Cryptographic Algorithm
          Tag: Attribute Value (0x42000B), Type: Enumeration (0x05), Data: 0x00000003 (AES)
        Tag: Cryptographic Length (0x42002A), Type: Integer (0x02), Data: 0x00000080 (128)
          Tag: Attribute Name (0x42000A), Type: Text String (0x07), Data: Cryptographic Length
          Tag: Attribute Value (0x42000B), Type: Integer (0x02), Data: 0x00000080 (128)
        Tag: Cryptographic Usage Mask (0x420002C), Type: Integer (0x02), Data: 0x0000000C (Encrypt, Decrypt)
          Tag: Attribute Name (0x42000A), Type: Text String (0x07), Data: Cryptographic Usage Mask
          Tag: Attribute Value (0x42000B), 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 is a structure (see Table 2) used for sending and receiving Managed Object attributes.
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
Object

Encoding

REQUIRED

Attribute

Structure,
or same as Attribute Value



Attribute Name

Text String

Yes - by Custom Attribute, only [see 3.39]

Attribute Index

Integer

No

Attribute Value

Varies, depending on Attribute

Yes - except for the Notify operation [see 5.1]



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]