PyKMIP server (wrongly?) not enforcing unique name attr

[tomholub]

Thanks for your work on PyKMIP.

We tested our software using PyKMIP server as well as SmartKey KMIP server. SmartKey enforces unique object names, so I'll get an error if I try to save second object with the same name:

com.flowcrypt.kmip4j.KmipException: sobject already exists

PyKMIP will however save several objects with the same name.

Here the spec at http://docs.oasis-open.org/kmip/spec/v1.0/os/kmip-spec-1.0-os.html#_Toc262581174 says:

Names SHALL be unique within a given key management domain, but are not REQUIRED to be globally unique.

Which sounds to me that within a namespace (belonging to a particular client), names should be unique.

But I'm not 100% sure I'm reading it correctly, as they don't explicitly say to refuse non-unique ones. But if they say that names SHALL be unique, the only way to do that is to refuse any conflicting records.

[PeterHamilton]

Hi @tomholub, thanks for filing this issue. You're correct, the PyKMIP server does currently support duplicate names on multiple managed objects. That was a design decision that was made long ago and has stuck around ever since.

The issue lies with how the KMIP spec defines a key management domain; in short, it doesn't. The notion of a domain or object namespace is left up to individual server implementations and is not really addressed in the KMIP spec itself (object groups sort of get at this idea but not directly). As a result there are only two reasonable interpretations; the entire space of objects managed by the server is one domain, or each object belongs to its own domain. For simplicity and to support certain use cases, we (long ago) opted for the second option, so the server enforces the unique name limit on individual objects (i.e., you cannot have multiple identical names on the same object).

I'm happy to reconsider this design issue, as it wouldn't require much work to fix. If this is something you'd like to see, I'll add it to our feature list for our next milestone.

For now, do not use the object name as a unique identifier for the object. Only the object's actual unique identifier will serve that role.

[tomholub]

We use PyKMIP for automated tests, so from my point of view, best would be to do whatever most KMIP servers are doing. I was only able to test one vendor (SmartKey) which does enforce unique names. But that's only one datapoint. Do you happen to know what most KMIP server vendors do?

[PeterHamilton]

Do you happen to know what most KMIP server vendors do?

I don't unfortunately. It's been a while since we actively tested against third-party KMIP appliances.

I'll go ahead and mark this as a feature request for the v0.11 release and will try and take a look at the dev work for it in the near future.

[tomholub]

Got it - sounds great.