RE: [kmip] Groups - proposal_for_attribute

There are going to be situations where the attribute with index 0 has been deleted. We in fact address this case in section 2.1.6 of the spec and section 3.21 of the Usage Guide. If the Cryptographic Parameters attribute is omitted in the Encryption Key Information and multiple instances exist, the server does not assume the index value to be 0, but is expected to use the attribute with the lowest attribute index.

-Indra

From: Tim Hudson [mailto:tjh@cryptsoft.com]
Sent: Tuesday, August 23, 2011 3:23 PM
To: Bruce Rich
Cc: kmip@lists.oasis-open.org
Subject: Re: [kmip] Groups - proposal_for_attribute_index-v1.doc uploaded

On 24/08/2011 7:26 AM, Bruce Rich wrote:

Hmm, what do we do for the Custom Attributes ("x-*" and "y-*")? For the y-*, the server should know whether they are multi-valued, so can know whether or not to return a 0 index for the first/only instance. But for custom client attributes, the server doesn't know that it's multi-valued until the second AddAttribute for the same x- name.

I think we may need to assume that custom client attributes are always multi-valued and thus the server always includes an index for x- attributes

The attribute index handling should be identical for all attributes - entirely independent of whether they are custom attributes or multi-valued.

There are a couple of choices:
- either an index value shall always be provided; or
- if an index value is not present it shall be assumed to be '0'

That's how it should be handled in all contexts - a rather simple rule.

The whole approach of having different rules for how to handle is what the proposal is about addressing - to get back to a simple situation - and one where there is a chance that implementations will actually be able to match the specification :-)

Tim.

kmip message