RE: [kmip] More on Clarification of Cryptographic Parameters

Tim,

The behaviour you have specified for crypto parameters with crypto operations is different to the behaviour for the wrap function. Both use crypto parameters specified by the client or associated with the key. If you believe that the new crypto operations CP behaviour is correct, then for consistency, the behaviour for wrap needs to change to match. I believe this would be the wrong thing to do. It would be incompatible with v1.0 and v1.1. And it’s something that you have not proposed. Therefore…

If you believe that there should be inconsistent behaviour, you need to argue the case for inconsistency. To make this clearer, you need to put forward a compelling case for why, for example, when a server wraps a key, the CP provided by the client MUST MATCH the CP (if present) associated with the wrapping key, but in contrast to this, when a server encrypts data, the CP provided by the client IS USED, AND NEED NOT MATCH the CP (if present) associated with the encryption key.

You used a consistency of CP behaviour argument prior to the vote for the crypto operations proposal into the standards work, but the Usage Guide text, and example above, clearly show that your argument was wrong. Your proposal is clearly inconsistent, therefore the argument you used prior to the vote is invalid – in fact, misleading. The proposed new crypto operations behaviour is not consistent with usage of crypto parameters by the server for wrap, or recommended for clients when they perform other crypto operations themselves.

The behaviour that I have proposed is consistent with the server wrap behaviour, and client crypto operations behaviour. It is sensible behaviour. It is secure behaviour. It is consistent with the text in the Usage Guide since 1.0.

Finally, I think you are confusing management of crypto parameters with usage of crypto parameters. I am not proposing any changes to the management of crypto parameters. This remains exactly as it has always been. The client can add, modify, and delete crypto parameters. Cryptographic operations are not meant to be used for managing crypto parameters. Crypto operations use crypto parameters. This is an important difference, and one that can be easy to miss when insufficient rigour is applied in proposing and reviewing behaviour.

John

From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Tim Hudson
Sent: Friday, 26 July 2013 11:25 AM
To: kmip@lists.oasis-open.org
Subject: Re: [kmip] More on Clarification of Cryptographic Parameters - Usage Guide

On 26/07/2013 10:47 AM, John Leiseboer wrote:

In your previous arguments – the ones that perhaps swayed people to vote in favour of the crypto operations proposal – you very strongly asserted that your proposal was strictly in line with the existing “model” for Crypto Parameters.

The Cryptographic Parameters associated attribute is entirely under the control of the client - it can be added, modified and deleted. It can be present, be not present, and have multiple values. That is how it always has been in KMIP 1.0 and KMIP 1.1. Nothing you've stated over the last year on this topic overcomes that fundamental fact. The changes in the specification were done with explicit text to note the behaviour (based on your feedback) and discussed at length prior to the ballot.

It is not a mistake - it isn't unclear text - it isn't open to multiple interpretations. It just happens to not be what you believe should be in place.

The tests we have in place during interop can always be improved and expanded - and in fact they have been substantially expanded in KMIP 1.2 and we have added tests for functionality that has been defined since 1.0 and never have had test cases. We still have functionality that was defined in KMIP 1.0 which has no tests, and we also have functionality within KMIP 1.0 that no one has yet implemented. All of these are items we can continue to work on as we improve things. None of these however are reasons to hold up KMIP 1.2 - as if you accepted the argument you are making then we still would not have a KMIP 1.0.

A number of TC members have invested heavily in producing test cases, and a larger number of members have committed substantial resources to the two rounds of interop testing we are doing every year - all of those help make KMIP the interoperable key management standard that it is and differentiate KMIP from other standards (and OASIS from other standards bodies). If you want to invest Quintessence Labs resources in contributing more test cases I'm sure the TC would welcome that (I know we as a TC member we certainly would). However none of that is anything to do with whether or not KMIP 1.2 is ready. It has been reviewed and interop tested well beyond any prior version of KMIP to date.

Tim.

kmip message