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

["Frindell,Alan" <Alan.Frindell@safenet-inc.com>]

Hi Marcus, each of your examples seem to me like good reasons to allow the server to mutate some attributes.  My issue is that I think the use cases for mutation are limited, and should be specified explicitly in the spec, so conformant clients will know what values may change.  

The goal to have clients be relatively simple is what led me to think that server mutation should be restricted.  If mutation is unlimited, then clients need to have logic to handle the mutation of every attribute.

The downside risk to restricting mutation is that a server implementer later discovers a missed use-case, and must return a failure rather than a mutation.  I see that as a good thing for interoperability, since clients written to the specification will not know how to handle the mutation anyways.

If the set of mutatable attributes is sufficiently small, I would be OK with not allowing clients to "opt out" of the server mutation (option 3 in the poll).  Then again, since only clients opting-out would be subject to the "Dr. Suess" situation, I don't see the harm in having this option.  Based on the straw poll results, it seems those who voted do prefer to have this option available.

I think the best way to proceed is to collect the mutation use cases mentioned so far to use as a starting point for the allowed subset.

Thanks

-Alan

> -----Original Message-----
> From: Marcus Streets [mailto:Marcus.Streets@thales-esecurity.com] 
> Sent: Thursday, July 09, 2009 4:49 AM
> To: kmip@lists.oasis-open.org
> Subject: Re: [kmip] Re: Groups - oasis - Ballot "Straw poll 
> on whether to allow "mutating attributes" in KMIP V1.0." has closed
> 
> 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
> 
> ---------------------------------------------------------------------
> 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_workgr
> oups.php 
> 
> The information contained in this electronic mail transmission 
may be privileged and confidential, and therefore, protected 
from disclosure. If you have received this communication in 
error, please notify us immediately by replying to this 
message and deleting it from your computer without copying 
or disclosing it.