kmip-interop-tech — archive

[John Leiseboer]

Tim said: > On TC-312-12: > > The attribute indexes must be created in the order specified by the user > ... Attributes pulled in from a Template are meant to be > included first... > it is absolutely essential that the attribute index assigned to > the "first" value is indeed set to 0 so processing items in the reverse > order is indeed non-conforming. I've scoured the KMIP 1.2 specification and found reference to multi-instance Attributes as follows: Section 2.1.1 Attribute specifies what an Attribute is. This section does not specify the order in which indexes shall be applied to multi-instance Attributes. Table 2 appears to permit the Attribute Index to be assigned by the client (which may be useful when it is important for the client to deterministically retrieve specific instances). Note that section 4.14, Add Attribute, specifies that clients SHALL NOT specify the Attribute index in the Add Attribute request. Nothing here saying that a server cannot apply indexes in any order it likes (except of course when there is only one attribute - it gets index 0). Section 2.2.6 Template specifies what a Template is. It places no requirements on ordering of indexes for multi-instance Attributes in the Template and/or outside the Template. Nothing here saying that a server cannot apply indexes in any order it likes. Section 3 Attributes defines Attributes. Multi-instance Attributes are defined. Table 43 specifies Attribute Rules. There are no requirements stated here on the ordering of Attribute indexes. Nothing here saying that a server cannot apply indexes in any order it likes. Section 4 Client-to-Server Operations contains information specifying how to handle conflicts in values of single-instance Attributes. This section states this for multi-instance Attributes: "For multi-instance attributes, the union of attribute values is used when the attributes are specified more than once." There are no requirements stated here on the ordering of Attribute indexes. Nothing here saying that a server cannot apply indexes in any order it likes. Section 4.2 Create Key Pair states the requirements for the Create Key Pair operation. It states this about multi-instance attributes: "For multi-instance attributes, the union of the values found in the templates and attributes of the Common, Private, and Public Key Template-Attribute SHALL be used." This section also talks about precedence of values for single-instance Attributes. There are no requirements stated here on the ordering of Attribute indexes. Nothing here saying that a server cannot apply indexes in any order it likes. Section 4.5 Re-key Key Pair repeats what section 4.2 says about multi-instance attributes. There are no requirements stated here on the ordering of Attribute indexes. Nothing here saying that a server cannot apply indexes in any order it likes. Section 4.12 Get Attributes states the requirements for the Get Attributes operation. Regarding multi-instance Attributes it says: "If a specified attribute has multiple instances, then all instances are returned." There are no requirements stated here on the ordering of Attribute indexes. Nothing here saying that a server cannot apply indexes in any order it likes. Section 4.14 Add Attribute states the requirements for the Add Attributes operation. Regarding multi-instance Attributes, and index values, this section states: "For multi-instance attributes, this is how the first and subsequent values are created", and "The Attribute Index SHALL NOT be specified in the request. The response returns a new Attribute Index and the Attribute Index MAY be omitted if the index of the added attribute instance is 0." There are no requirements stated here on the ordering of Attribute indexes. Nothing here saying that a server cannot apply indexes in any order it likes. By stating that the Attribute index SHALL NOT be specified in the request, it is clear that a client cannot rely on the index value being what it may prefer it to be. Section 3.6 Template of the Usage Guide makes no mention of multi-instance attributes. There is no guidance here on the ordering of Attribute indexes. Nothing here saying that a server should not apply indexes in any order it likes. In summary, there are no requirements that I can find anywhere to support Tim's assertions that: 1. "The attribute indexes must be created in the order specified by the user..." 2. "Attributes pulled in from a Template are meant to be included first..." 3. "...processing items [JL note: for the purposes of Attribute index assignment] in the reverse order is ... non-conforming" If anyone can point me to anywhere in the standard, or even in the usage guide, that supports these assertions, then please do so. I can find nothing to support them. Tim, you are free to give your opinion on what should be done, but that does not mean that the QuintessenceLabs implementation is "indeed non-conforming", and it does not change what the standard actually says (or does not say). I would dearly like to hear other individuals' opinions please. The test cases are not normative. The test case document does state that behaviours other than those documented in the test cases may be conformant ("The test cases show one possible way to construct the messages, and the messages shown are not necessarily the only conformant constructions..."). Taken together with the actual wording of the standard, I cannot see why the QuintessenceLabs server behaviour for assigning multi-instance attribute values can be called non-conformant. My question to the group is whether a majority feel that this difference in behaviour can be accommodated in the test result, or not. Regards, John