Re: [kmip] Re: Groups - oasis - Ballot "Straw poll on whether to allow "mutating attributes" in KMIP V1.0." has closed

[Marcus Streets <Marcus.Streets@thales-esecurity.com>]

On the subject of mutations - one important reason to allow them is to
simplify key requests.

In the original design, the assumption was made was that the server was
complex and had full knowledge of the state of each key, while the
clients were relatively simple.

The intention was to reduce the number messages required to complete any
task.

If the server is not allowed to mutate the attributes requested by a
client we risk getting into a Dr Seuss situation where the client plays
the part of Sam and has to ask repeated questions until it gets the
answer right.

Allowing the server to mutate the request means that if for instance the
client requests a key and asks to be allowed to encrypt 1000 blocks but
the server knows that it has only 500 blocks left - we had two options:

- either return an error, hopefully with the maximum allowed value so
the client does not have to make repeated guesses.

- return the key with a note that it an only be used for 500 blocks.

Applying Occam's razor we went for the second option, to save a round trip.

When registering a key, if the client requests a lifetime that is
plainly wrong, for example suggesting a Triple DES key be used to
encrypt a Peta byte - the server needs to be able to correct this to a
sensible value.

Again it could reject the initial request and suggest correct values -
but again this just causes traffic. Alternatively it can register the
key and return the acceptable values.

Of course, if it is presented with a 3DES key it cannot register this as
an AES key - and if there is a policy that all keys be AES the server
has no option but to reject the key. If in this case the client cannot
use AES keys, there is a significant problem that no protocol can solve.

We should bear in mind that KMIP is only the server to client protocol -
not the complete server implementation. We must assume that if the
administrator attempts to enforce an AES only rule having registered
3DES only clients then the server will inform them that there is a
conflict.

-- 
Marcus Streets
Security Standards Officer

THALES Information Systems Security
nCipher product line

------------------------------------------------------
T:  +44 (0) 0123 723613 (Direct)
F:  +44 (0) 0123 723601
E:  Marcus.Streets@thales-esecurity.com
W:  www.ncipher.com