KMIP-interop-tech

If a private key is revoked (with compromised) what state should the public key be in after the revoke call? 1) unchanged 2) compromised 3) at the whim of the server selecting either 1) or 2) [i.e. by policy based on server policy configuration settings] We are certainly seeing different handling across the vendors participating in interop. Tim.

Since private keys are generally used for signing or decrypting, the public key should be moved to deactivated/process only. Revocation is not required because you still may need to use the public key for verification of items that were signed by the revoked/compromised private key. In this fashion you would no longer encrypt with the public key or sign with the private key. And another thought is that depending on the compromise of the private key should determine whether the public key goes to process only or compromised as the public key is very much a known value so compromise doesn't really apply to it. Now I just need to make sure that is what we actually do. Just thinking out loud. Bob L. -----Original Message----- From: kmip-interop-tech@lists.oasis-open.org [ mailto:kmip-interop-tech@lists.oasis-open.org ] On Behalf Of Tim Hudson Sent: Thursday, January 24, 2013 10:01 PM To: kmip-interop-tech@lists.oasis-open.org Subject: [kmip-interop-tech] Revoke If a private key is revoked (with compromised) what state should the public key be in after the revoke call? 1) unchanged 2) compromised 3) at the whim of the server selecting either 1) or 2) [i.e. by policy based on server policy configuration settings] We are certainly seeing different handling across the vendors participating in interop. Tim. --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

As a note, this discussion doesn't just apply to public-private key pairs, but to all manner of linked objects; Compromise of a private key can also affect certificates, while compromise of key derivation data can affect derived keys. > the public key is very much a known value so compromise doesn't really apply to it. 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. Also, users of the public key may/should not have access to the private key and its attributes. If it is desirable for them to distinguish between "a key pair, no longer in use", and "a key pair, no longer trustworthy", then this has to be done via the attributes of the public key; I believe setting the State of the public key to Compromised is the simplest way of doing this. -- Michael

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.

> 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. > I agree that it's a source of potential confusion. However, consider the case of Certificates. I'd argue that if the private key has been compromised, the associated Certificate is also compromised. While we could expect the client to handle the revocation, I'd argue that it's equally a source of potential confusion to have Active certificates with Compromised keys. Worse, it's also a source of potential security issues. So, should a server, when asked to perform a Verify operation, reject the certificate chain if it knows that one of the certificates was signed with a compromised key? If so, how should it communicate this to the client, which will have no access to the key's state? > The public key has a rather different life cycle to that of the private key and in > my view should indeed be managed separately. > Agreed for the standard key lifecycle. (Activate, Deactivate, Destroy). However, key compromise is not part of the normal lifecycle of a key, but rather an exceptional event, and deserves some degree of exceptional treatment. > 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. > Agreed. -- Michael