OASIS Key Management Interoperability Protocol (KMIP) TC

During the work on server-to-server extensions of KMIPv1, we came up with
few proposals for spec changes
that the TC might consider for inclusion already in the KMIPv1. The benefit
of this would be reducing the differences
between KMIPv1 and its future versions. These could be accepted as a part
of public review.

We believe that the changes proposed below are not strictly related to
server-to-server (although the need for them
appeared in this context). Furthermore, most of the changes seem pretty
lightweight and acceptable.

The proposed changes are included below. Best regards,
Marko Vukolic

----------------
Issue 1: The behavior of Put when Replaced Unique Identifier (ruuid) is
specified, but the object with ruuid does not exist
on the remote end (client) is not specified. Specifying this behavior might
enhance interoperability.

Proposed resolution:
The client (remote end) ignores the ruuid and acts like it was not
specified.

Issue 2: Notify does not support notification about deleted attributes.

Proposed resolution:
Augment Notify to support attribute deletion notification (to be detailed).

Issue 3: the optional support of wildcards in Locate is stated only for
Name and Object group. It is not clear why other
attributes that are represented as Strings are not supported by the
wildcards. This seems to be a leftover from the
early days of KMIP in which Locate supported only a subset of attributes.

(lines 1147-1149)

"1147 When using the Name or Object Group attributes for identification,
wild-cards or regular expressions
1148 (defined, e.g., in [ISO/IEC 9945-2]) MAY be supported by specific key
management system
1149 implementations"

Proposed resolution: replace in line 1147 "Name or Object Group" with
"Unique Identifier, Name, Certificate Identifier,
Certificate Subject, Certificate Issuer, Digest, Operation Policy Name,
Revocation Reason, Object Group, Link,
Application Specific Information or Contact Information".

Issue 4: Not possible to "Locate All" objects in KMIPv1.  This
functionality is
very useful in the server-to-server context but might be nice to have even
for client/server.

Proposed resolution:
Omitting all attributes from a Locate request could be interpreted as
"Locate All"

-------------------

All,

please find below a formal proposal for the s2s inspired changes to KMIPv1,
as discussed on the previous calls.

Regards,
Marko

---------------
 1) Proposed changes to Put

Add after sentence ending in line 1465:

"In case the object with the Replaced Unique Identifier does not
exist at the client, the client SHALL interpret this as if the Put
Function contained the value New."

2) Proposed changes to Notify

i) In the Description column of the Attribute Object in Table 164, add the
following as the last sentence.

In case an attribute was deleted, the Attribute structure (see 2.1.1) in
question SHALL NOT contain the Attribute Value field.

and

ii) in Table 1, row Attribute Value, column "REQUIRED":

"Yes" should be replaced with "Yes, except for the Notify operation (see
Section 5.1.)

3a) Proposed change to Locate

The sentence in lines 1147-1149 should be replaced with the following:

"Wild-cards or regular expressions (defined, e.g., in [ISO/IEC 9945-2])
MAY be supported by specific key management system implementations
for matching attribute fields when the field type is a Text String or a
Byte String."

3b) Proposed change to Locate

i) The following sentence replaces the first sentence of the text of
Locate:

 "This operation requests that the server search for one or more Managed
Objects
depending on the attributes specified in the request."

and

ii) the following sentence should be added to the text after the sentence
ending in line 1138:

"If no attribute is specified in the request, any object SHALL be deemed to
match the Locate request.

and

iii) in table 127, row "Attribute", column "REQUIRED", the text should be
changed to:

"No, MAY be repeated"
--------------------


                                                                                                                                       
  From:       Marko Vukolic2