RE: [kmip] TTLV encoding concern

["Featherstone, David" <David.Featherstone@safenet-inc.com>]

Mark, Tim

 

Responding in order of replies received …

 

Mark Joseph wrote:

> 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.

 

My proposal maintains the ‘x-‘ and ‘y-‘ prefixes specified for custom attributes.  Of course, no client- or server-defined attribute could be expected to have an associated object tag defined in the KMIP specification; rather, the specification defines a single Custom Attribute (42002D) whose Attribute Name field serves to distinguish one Custom Attribute from another. For example:

 

        Tag: Custom Attribute (0x42002D), Type: Structure (0x01), Data:

          Tag: Attribute Name (0x42000A), Type: Text String (0x07), Data: x-My Custom Client Attribute

          Tag: Attribute Index (0x420009), Type: Integer (0x02), Data: 0x00000002 (2)

         Tag: Attribute Value (0x42000B), Type: Integer (0x02), Data: 0x00000011 (17)

 

Only a Custom Attribute strictly requires the presence of the Attribute Name field. The object tag is sufficient to prime the parser to anticipate the mandatory and optional fields:

Attribute Name:              REQUIRED=Yes (and must be prefixed by ‘x-‘ or ‘y-‘)

Attribute Index:               REQUIRED=Yes, if Index!=0

Attribute Value:               REQUIRED=Yes, except when present in a Notify

 

So, Custom Attributes are distinguished from each other by their x- or y-prefixed Attribute Names. The Custom Attribute’s associated object tag (0x42002D) does the job of any object tag: Within a KMIP PDU, it serves to delimit its corresponding KMIP element.

 

Tim Hudson wrote:

> What you are actually asking for is an incompatible change to the basic

> encoding used for attributes - not a clarification.

 

Actually, the proposal is completely forward-compatible with existing usage. In fact, the existing encoding (---) and the proposed encoding (+++) could be intermixed in the same KMIP request or response without conflict:

 

 

+++ Tag: Cryptographic Algorithm (0x420028), 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: Cryptographic Usage Mask (0x420002C), Type: Integer (0x02), Data: 0x0000000C (Encrypt, Decrypt)

--- Tag: Attribute (0x420008), Type: Structure (0x01), Data:

---   Tag: Attribute Name (0x42000A), Type: Text String (0x07), Data: x-attribute1

---   Tag: Attribute Value (0x42000B), Type: Text String (0x07), Data: Value1

+++ Tag: Custom Attribute (0x42002D), Type: Structure (0x01), Data:

+++   Tag: Attribute Name (0x42000A), Type: Text String (0x07), Data: x-attribute2

+++   Tag: Attribute Value (0x42000B), Type: Integer (0x02), Data: 0x00000011 (17)

 

 

As for the clarity/ambiguity of the specification, I believe that the text of Section 3.39 Custom Attribute clearly indicates that attributes were expected to be encoded as I am proposing:

 

3.39 Custom Attribute

A Custom Attribute is a client- or server-defined attribute intended for vendor-specific purposes. It is

created by the client and not interpreted by the server, or is created by the server and MAY be interpreted

by the client. All custom attributes created by the client SHALL adhere to a naming scheme, where the

name of the attribute SHALL have a prefix of 'x-'. All custom attributes created by the key management

server SHALL adhere to a naming scheme where the name of the attribute SHALL have a prefix of 'y-'.

The server SHALL NOT accept a client-created or modified attribute, where the name of the attribute has

a prefix of ‘y-‘. The tag type Custom Attribute is not able to identify the particular attribute; hence such an

attribute SHALL only appear in an Attribute Structure with its name as defined in Section 2.1.1.

 

The paragraph states that tag type is not sufficient to identify a Custom Attribute, but correctly infers that every other Attribute can be identified by its object tag.  If attributes were not expected to be identified by object tag, there would have been no need to even mention “tag type” in the above description.

 

Regards,

… Dave

 

 

 

From: Tim Hudson [mailto:tjh@cryptsoft.com]
Sent: Friday, June 27, 2014 11:07 PM
To: Featherstone, David; kmip@lists.oasis-open.org
Subject: Re: [kmip] TTLV encoding concern

 

On 27/06/2014 5:38 PM, Featherstone, David wrote:

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.

It isn't a misapplication - it is a choice made by the technical committee long ago (and in fact actually predates the specification moving into OASIS).
Attributes are always encoded in that manner. The specification is clear.

There are other ways it could have been done which would have been much more efficient - but that isn't what the specification states.

The "encoding" items with in the definition of the structure refer to each field (labelled as an object) - and the specification is rather clear - that an attribute shall always have an attribute value tag - and that the encoding (i.e. the type used for that tag) varies depending on the attribute itself.

What you are actually asking for is an incompatible change to the basic encoding used for attributes - not a clarification.

Tim.

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.