kmip-interop-tech — archive

[Tim Hudson]

On 16/01/2016 3:13 PM, John Leiseboer wrote: > If anyone can point me to anywhere in the standard, or even in the > usage guide, that supports these assertions, then please do so. If the server was free to be able to allocate the attribute index in any order within a request then there would be nothing within the specification that referred to using an attribute based on the index value (i.e. if the client was unable to ensure that a particular order was used for an attribute then there would be nothing in the specification for client attribute to be selected based on its attribute index value if the client has no way to be sure what order attributes indexes are assigned). The specification also clearly states that attribute indices start at 0. Cryptographic Parameters is an attribute controlled by the client (set by client, modifiable by the client, deletable by the client and not modifiable by the server). Numerous references in the specification reference using the "lowest Attribute Index". If a client registers with two Cryptographic Parameter values (specified in whatever manner either via the deprecated template reference mechanism or directly) then the client must be able to have confidence as to which of the Cryptographic Parameter values it is providing is what the client intends be used in all the circumstances where the "lowest Attribute Index" is noted. If two servers are able to pick different orders (as you assert) then the result is non-interoperable for this sort of usage. Like many things within KMIP you have to follow the underlying model (that we have both previously discussed isn't captured explicitly in the specification) and that interoperability is what is intended to be used to guide the areas of the specification where the context isn't as detailed as we might want it to be. Tim.