Re: [kmip] Use cases for mutating attributes

[Matt Ball <Matthew.Ball@Sun.COM>]

Offhand, I think in many of these use-cases, it seems that it would be
better to return some kind of error than to quietly 'correct' the
attributes.  In the example with a 3DES key protecting a petabyte of
data, it would be better for the server to return an error than to
correct the value to what the server assumed that the client had
originally intended.  Maybe the client really wanted an AES key, and
accidentally chose 3DES.

As a group, we need to be very careful about what attributes we allow to
change, because it's likely covering up some other systematic problem. 
These are often use-cases that should result in an error.

Cheers,
-Matt

Frindell,Alan wrote:
> I collected the examples given for why the server may have legitimate cause to mutate an attribute.  If someone has another use case, please send it out to the list.
>
> For each example, I tried to list which Attributes could be mutated.
>
> From Robert Haas:
>
> * Collisions with already assigned names
>
> Affected Attributes: Name, Application Specific ID
>
>
> * Backdating of the lifecycle dates
>
> Affected Attributes: Activation Date, Process Start Date, Protect Stop Date, Deactivation Date
>
>
> * Use of algorithm parameters considered insecure. 
>
> Affected Attributes: Cryptographic Length, Cryptographic Parameters (Cipher mode, Padding, Hash Algorithm, Role Type), Cryptographic Usage Mask
>
>
> From Marcus Streets:
>
> * Client requests a key and asks to be allowed to encrypt 1000 blocks but
> the server knows that it has only 500 blocks left.
>
> Get Usage Allocation explicitly allows the server to return an allocation smaller than requested.
>
> * 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.
>
> Affected Attributes: Usage Limits
>
>
> I think sanitizing lifecycle dates and usage limits are an acceptable use of mutations that clients can adapt to without significant effort.  
>
> Changing names and cryptographic parameters, however, could make things very challenging for clients.  How can the server intelligently modify a client requested name and be sure it still serves the client's purpose?  How does the server know that the client can perform a cryptographic function with a longer key, or a different cipher mode?  I think interoperability may be better served by not allowing such mutations.
>
> Thanks
>
> -AlanThe 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.
>
>
>
> ---------------------------------------------------------------------
> 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
>
>   
begin:vcard
fn:Matt Ball
n:Ball;Matthew
org:Sun Microsystems, Inc.;Key Management
adr:;;500 El Dorado Blvd, Bldg 5;Broomfield;CO;80021;U.S.A.
email;internet:matthew.ball@sun.com
title:Staff Engineer
tel;work:303-272-7580
tel;fax:303-272-3023
tel;cell:303-717-2717
x-mozilla-html:TRUE
url:http://www.sun.com
version:2.1
end:vcard