Greetings
John Leiseboer's email [regarding Derived Key Operation] prompted me to point out some additional inconsistencies in the KMIP spec:
- Every attribute's description includes a table indicating whether the value(s) comprising the attribute are REQUIRED [i.e. Yes or No]. Simple [or non-Structure] attributes [e.g. Unique Identifier, Object Type] are defined by a single element [e.g. a Text
String, an Enumeration]. Complex [or Structure] attributes [e.g. Name] are defined by a plurality of elements [e.g. Text String *and* Enumeration]. Section 3 of the specification generally indicates that every element comprising a Structure attribute is Required
[=Yes].
The inconsistency occurs in Section 4.9 Locate, which states:
1143 When an attribute that is defined as a structure is specified, all of the structure fields are not REQUIRED
1444 to be specified. For instance, for the Link attribute, if the Linked Object Identifier value is specified without
1445 the Link Type value, then matching candidate objects have the Linked Object Identifier as specified,
1446 irrespective of their Link Type.
A short statement at the beginning of Section 3 could alert the reader to the fact that a Structure's "Required" elements are not always required.
- Section 3.4 Cryptographic Algorithm, Rules Table, states that this attribute is set only by the Server. The fact that the client can provide this attribute in a Create request [as just one example] is evidence that a Client can indeed set this attribute.
(To suggest that the Client only directs the Server, such that is actually the Server that sets the value, would mean that all attributes are settable only by the Server and never by the Client.)
- Ditto the above for Section 3.5 Cryptographic Length.
- Section 4.4 Re-Key states:
1242 As the replacement key takes over the name attribute of the existing key, Re-key SHOULD only be
1243 performed once on a given key
However, the Name attribute is a multi-instance attribute. Section 4.4. Re-key should clarify whether the first Name instance, the last Name instance, or all Name instances are inherited by the replacement key.
- Ditto the above for Section 4.5 Re-key Key Pair
- Section 2.1.1 Attribute states:
213 2.1.1 Attribute
214 An Attribute object is a structure (see Table 2) used for sending and receiving Managed Object attributes.
215 The Attribute Name is a text-string that is used to identify the attribute. The Attribute Index is an index
216 number assigned by the key management server. The Attribute Index is used to identify the particular
217 instance. Attribute Indices SHALL start with 0. The Attribute Index of an attribute SHALL NOT change
218 when other instances are added or deleted. Single-instance Attributes (attributes which an object MAY
219 only have at most one instance thereof) SHALL have an Attribute Index of 0. The Attribute Value is either
220 a primitive data type or structured object, depending on the attribute.
This section is incomplete in that it does not address Index re-use of a previously deleted attribute instance. e.g. This section might (additionally) say:
Option-A: For a given multi-instance attribute, the Attribute Index SHALL NOT be reused over the life of the associated Managed Object.
Option-B: For a given multi-instance attribute, Attribute Index=0,1,2,… MAY be reused only after all other instances of the Attribute have been deleted.
Option-B is consistent with the fact that a single-instance attribute, once deleted and then re-created will still have Attribute Index=0. (I suppose that this behavior, too, might be questioned. i.e. Perhaps a single-instance
attribute’s Attribute Index should vary with every new (single) instance.)
Regards,
… Dave