Re: [kmip] KMIP spec inconsistencies

[Tim Hudson <tjh@cryptsoft.com>]

On 20/12/2014 3:45 AM, Featherstone, David wrote:
>
>  1. 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.

The attribute structure is used both for the representation of
Attributes where the rules are clear and (for example) as a mechanism
for passing in search parameters in Locate (which you should note isn't
an attribute and isn't defined in section 3). In the context of use as a
parameter the "rules" are different and are clearly stated where they
are different. A simple fixed mapping of the structures defined within
the specification and then electing to share those same fixed attribute
value structures with their use as parameters in operations as an
implementation approach doesn't work as they are in also in numerous
places variant records.

> 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.
But they are except in the context where they are explicitly noted as
not - all of which are outside the Attribute section (Section 3) where
those rules are defined.
So adding any such a statement would actually be incorrect in the
context of Section 3.


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

Stating "Server" means that the client cannot set the value of the
attribute using any of the Attribute operations. If you read Table 42
which defines what those values mean where you will see that "Initially
set by" means "Who is permitted to initially set the value of the
attribute (if the attribute has never been set, or if all the attribute
values have been deleted)?" and if the client is permitted then that
means via the operations available to the *client *for dealing with
attributes - i.e add/modify/delete attribute - which in this context is
talking about the use of the Add Attribute operation.

Where the client is providing a set of attributes in the constructors it
is as you suggest providing values for the server to determine if they
are acceptable - it is not directly setting the value in that context -
it is a distinction which could be made clearer I guess. Although the
text in the Add/Modify/Delete Attribute operations does state "This
operation requests the server to ..." which isn't helpful to the
explanation here where we are distinguishing a request by a client after
the object has been constructed to the context of parameters for
constructing the object itself - so I do get the point you are making
that the reader is required to understand a context of usage which isn't
clearly stated. A reference to what is meant in terms of the operations
involved I think would address that concern and to explicitly note that
the attributes being provided in the constructors and how that is
handled conceptually.

You have to look for attributes which are defined as not always
requiring a value, initially set up client, and deletable by the client
to get to a context where you have an attribute which does not have to
have a value set after the constructor has completed and hence not by
the "server" as such to get those examples to work through. Contact
Information is a good one to use without getting entangled in the
properties of the underlying object itself (i.e. something not related
to cryptographic information or usage).


>  2. 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.
Incorrect in that the specification states the handling for Name
explicitly as "Set to the name(s) of the existing key; all name
attributes are removed from the existing key." in ReKey, ReKeyKeyPair
and ReCertify. It might not be the behaviour that you would like but it
is entirely consistent with the use of Name being a client specified
unique value - contrast that with Alternative Name which is effectively
the same thing added without the unique value requirement. Alternative
Name doesn't require any special handling because it doesn't have that
unique value rule - nor is it something where in the context of rekeying
makes sense to be created relative to the values of the existing key.

> 5.
>
>
>  6. 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.)

The specification simply does not define or require a particular
approach. It was discussed at the time (and subsequently) as to whether
or not to allow or preclude re-use or attribute indexes and whether or
not to require monotonically increasing attribute index values and the
decision was to leave that up to the server implementation. A client
should not assume any particular allocation strategy. What the
specification states is effectively that the first index is 0 (SHALL
start with 0) and (as of KMIP 1.2) in all instances where the attribute
index is not specified it means 0 (in prior versions of KMIP there were
operations where there was a different interpretation specified for
non-specified attribute index values in the context of a parameter to an
operation). The client does not control the attribute index value
assigned. The server is not permitted to change the attribute index
value for a given instance of an attribute once allocated.

Personally I would like to see it stated that attribute index values for
non-single instance attributes are never reused - but there was not a
clear consensus on taking that approach back in KMIP 1.0 or any of the
times it has been discussed that I've been involved in since then. I'd
argue your Option-B isn't useful - in that for a client you want to know
if you have otherwise kept track of a specific instance (index value)
then you are always referring to precisely that instance of the attribute.

This is all pretty moot however in that the only place the client gets
to specify the attribute index is in the Modify Attribute and Delete
Attribute operations - as Get Attributes always returns all instances of
an attribute. I have previously suggested enhancing the Get Attributes
operation to allow the specification of the Attribute Index but that
also hasn't reached a consensus view previously.

This really also only comes into play in Custom Attributes - as for all
the defined attributes currently in the specification it is a matter of
it being "any-one-of-these-values" for any of the checks required within
KMIP - so the actual specific instance isn't relevant - in terms of
being something a client would need to remember - it is that any one of
the instances has a specified value - it only matters when modifying or
deleting a specified instance. We could also have a Modify Attribute or
Delete Attribute variation that allows specifying the value of the
attribute instance we are wanting to work on - and then clients for the
most part could entirely ignore the attribute index values (at least for
all non-custom attributes).

One area of previous discussion was defining some use cases around the
use of multi-instance custom attributes - and corresponding profiles and
test cases ... so if this is an area of interest to you then we should
look at considering this area for KMIP 1.4 and/or KMIP 2.0.

Tim.