OASIS Key Management Interoperability Protocol (KMIP) TC

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

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.

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.

On 28/06/2014 1:35 PM, Featherstone, David wrote: 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: Current servers and clients will not process what you are proposing as a change ... so any change like this would have to go into a later release of the specification - it cannot be handled in KMIP 1.0, 1.1 and 1.2 as specified. The specification itself doesn't not allow for an attribute to be encoded in that format. The challenge you face in trying to interpret that into the specification is the attribute structure itself is well defined - and it contains nothing within that text which would permit the sort of encoding you are suggesting. The text within Custom Attribute is simply making it clear there is no Tag corresponding to a custom attribute - so it you wanted a custom attribute to appear encoded anywhere within the protocol it will always be within an attribute structure. However (contrasting things) for example a Cryptographic Algorithm is an attribute and is also present within a number of structures outside the context of an attribute encoding - that is what the text is about there. Tim.

Hi Tim   I do not seek backward compatibility with KMIP 1.0, 1.1, or 1.2; rather, I seek forward-compatibility with KMIP 1.3+.   Cheers, … Dave     From: Tim Hudson [mailto:tjh@cryptsoft.com] Sent: Thursday, July 10, 2014 3:33 PM To: Featherstone, David; Mark Joseph Cc: kmip@lists.oasis-open.org Subject: Re: [kmip] TTLV encoding concern   On 28/06/2014 1:35 PM, Featherstone, David wrote:   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: Current servers and clients will not process what you are proposing as a change ... so any change like this would have to go into a later release of the specification - it cannot be handled in KMIP 1.0, 1.1 and 1.2 as specified. The specification itself doesn't not allow for an attribute to be encoded in that format. The challenge you face in trying to interpret that into the specification is the attribute structure itself is well defined - and it contains nothing within that text which would permit the sort of encoding you are suggesting. The text within Custom Attribute is simply making it clear there is no Tag corresponding to a custom attribute - so it you wanted a custom attribute to appear encoded anywhere within the protocol it will always be within an attribute structure. However (contrasting things) for example a Cryptographic Algorithm is an attribute and is also present within a number of structures outside the context of an attribute encoding - that is what the text is about there. 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.

On 10/07/2014 3:57 PM, Featherstone, David wrote: Hi Tim   I do not seek backward compatibility with KMIP 1.0, 1.1, or 1.2; rather, I seek forward-compatibility with KMIP 1.3+. Thanks - it is important to understand the context there - as your original message was basically claiming that the current interpretation was incorrect and that what you suggested was how you thought the specification was indicating it should actually be done. You presented it as errors ... If you are now suggesting that you'd like to change the basic encoding of template attribute handling going forward then that needs to be made clear. Thanks, Tim.