[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Broader View of Conformance
I wanted to re-iterate what I talked about on the last
conference call in looking at conformance at a higher level. I have a
concern that multiple server profiles will fragment adoption and increase the
complexity and/or frailty of interoperability. Here’s the scenario I’d like to avoid. Say
I purchase a KMIP conforming server for tape devices, then later
purchase/upgrade some client product that also claims “KMIP
Conformance” but the new client needs a different profile from the
server, so I get a second key management server. After a few iterations I
may end up with several KMIP implementations across the enterprise (compounded
by any added features from vendor extensions). The end result is that my
key management now looks like the picture of what KMIP is trying to solve:
isolated key management instances that can only support a fraction of the
clients in my network. Here’s what I would propose, a single KMIP profile for
servers, that should support whatever client gets thrown at it. This
makes the server interchangeable in the network. It will be more work to
create a KMIP Server, but there shouldn’t be many of them in an
enterprise anyway. The clients are compliant only in the requests they
choose to make. If a client won’t ever request asymmetric keys,
they wouldn’t have a need to support it and it would still be conforming
to the standard. Thanks, |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]