kmip-interop-tech — archive

[John Leiseboer]

> On 27/01/2013 10:32 AM, Michael Stevens wrote: >> I'd argue that what's actually being compromised is the key pair as a >> whole. For compromises, as with rekeying, dividing the key pair into >> its components and attempting to handle them separately doesn't make a > >lot of sense. > > In KMIP the private and public keys are entirely independent in terms of > being separate managed objects each with their own state. We didn't > elect to model a KeyPair as a managed object - and that means > automatically changing the state of another managed object when > something occurs is a source of a whole pile of confusion for users. Another way to approach this is to leave it to server policy. And I think that this would be the correct way to handle it. Sure this makes it hard for a client to predict what will happen. But clients cannot expect to always know server policy, and no client should ever presume to know server policy. Nor can a client expect that the request/response is handled as an atomic action, which in the extreme, could mean that in practical situations many of our test cases would fail. Getting back to the specific test case in question, both responses are correct. If you want to force a result one way or another, then it will be necessary to specify the server policy to be applied. And as server policy implementation is out of scope for KMIP, so is dictating how revoke is handled for key pairs, or other linked objects on any one vendor’s server. John