OASIS Key Management Interoperability Protocol (KMIP) TC

I think allowing the server to choose a value for an attribute other
than the value sent by the client in a request is going to make
interoperability more challenging.  As currently defined, the client
must be ready for the server to override (mutate) any attribute.  There
may be cases where the client application would prefer the request fail
than have a particular attribute mutated.  

I think by default the server should either accept the all of the
client's requested values, or fail the request entirely.  There can be
specific allowances in the specification for attributes where mutation
is deemed acceptable.  I think this eases the interoperability challenge
for clients by limiting the scope of what is allowed to change.


-Alan Frindell
SafeNet, Inc.
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.

Alan,

The main reasons why a server (according
to its server-specific policies) might decide to fail a request or instead
mutate the client-provided attribute value are mainly to prevent:

- collisions with already assigned names,
- backdating of the lifecycle dates,
- use of algorithm parameters considered
insecure.

Such situations should be rather infrequent.


Regards,
-Robert

"Frindell,Alan" <Alan.Frindell@safenet-inc.com>
wrote on 06/10/2009 07:53:32 PM:

>

> I think allowing the server to choose a value for an attribute other

> than the value sent by the client in a request is going to make

> interoperability more challenging.  As currently defined, the
client

> must be ready for the server to override (mutate) any attribute.  There

> may be cases where the client application would prefer the request
fail

> than have a particular attribute mutated.  

>

> I think by default the server should either accept the all of the

> client's requested values, or fail the request entirely.  There
can be

> specific allowances in the specification for attributes where mutation

> is deemed acceptable.  I think this eases the interoperability
challenge

> for clients by limiting the scope of what is allowed to change.

>

>

> -Alan Frindell

> SafeNet, Inc.

> 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.

>

>

>

>

> ---------------------------------------------------------------------

> 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

>

I think failing the request would make more sense, even 
in these cases.
 
thanks,

Rod Wideman
Quantum Corporation
(please disregard the confidentiality statement 
below)




From: Robert Haas [mailto:rha@zurich.ibm.com]
Sent: Thursday, June 11, 2009 8:52 AM
To: 
Frindell,Alan
Cc: kmip@lists.oasis-open.org
Subject: Re: 
[kmip] Mutating Attributes



Alan,

The main reasons why a server (according to its 
server-specific policies) might decide to fail a request or instead mutate the 
client-provided attribute value are mainly to prevent:

- collisions with already assigned names,
- backdating of the lifecycle dates,
- use of algorithm parameters considered 
insecure.

Such situations should be 
rather infrequent.


Regards,
-Robert

"Frindell,Alan" <Alan.Frindell@safenet-inc.com> 
wrote on 06/10/2009 07:53:32 PM:
>
> I think allowing the server to 
choose a value for an attribute other
> than the value sent by the client 
in a request is going to make
> interoperability more challenging. 
 As currently defined, the client
> must be ready for the server to 
override (mutate) any attribute.  There
> may be cases where the 
client application would prefer the request fail
> than have a particular 
attribute mutated.  
>
> I think by default the server should 
either accept the all of the
> client's requested values, or fail the 
request entirely.  There can be
> specific allowances in the 
specification for attributes where mutation
> is deemed acceptable. 
 I think this eases the interoperability challenge
> for clients by 
limiting the scope of what is allowed to change.
>
>
> -Alan 
Frindell
> SafeNet, Inc.
> 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.
>
>
>
>
> 
---------------------------------------------------------------------
> 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
>

The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum Corporation. Furthermore, Quantum Corporation is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.