OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: KMIP spec inconsistencies


Greetings
 
John Leiseboer's email [regarding Derived Key Operation] prompted me to point out some additional inconsistencies in the KMIP spec:
 
  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.
 
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.
 
  1. 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.)
  2. Ditto the above for Section 3.5 Cryptographic Length.
  3. 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.
 
  1. Ditto the above for Section 4.5 Re-key Key Pair
 
  1. 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
 
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.







[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]