kmip-interop-tech — archive

[Tim Hudson]

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. The public key has a rather different life cycle to that of the private key and in my view should indeed be managed separately. I can understand under some circumstances you might want to also update the state of the public key but doing that automatically and without the KMIP client having any control over it is concerning for interoperability and usability. The same argument as I mentioned could be equally applied in other areas and I don't think this is an area where there is a general universal solution - but it is something where if server vendors are going to take a different path and there is no guidance within the specification or the usage guide (and there is none currently from my reading of the documents) then we need to open this up to a broader discussion in the wider group. The new profile based test cases are basically trying to capture an expected life cycle for a class of applications - and this is the sort of thing which does need to be clear. And in ReKeyKeyPair the private key unique identifier is passed in explicitly and the operation notes that it will impact the linked public key. Although there is no note in the error handling for what should happen with the public key is not present (you can register just the private or CreateKeyPair and then delete the public so it is entirely possible to have only a private key as a managed object in a KMIP server). Tim.