Re: [kmip] Mutating attributes

[Robert Haas <rha@zurich.ibm.com>]

Regarding the removal of attribute mutation
in server's responses: during last week's call there were two comments,
and I promised to look into them:

1) Todd indicated that some protocols
have a "warning code" in their response messages. The warning
code indicates that the server completed the operation but not exactly
as requested by the client. With mutation being forbidden, the server can
either complete the operation as requested by the client, or otherwise
fail it with "Invalid Field" as Result Reason if the requested
attribute values are not acceptable. Note that this does not provide any
information to the client regarding which attribute value(s) were not acceptable.
We had discussions about including a payload in the error response message
to list what would be acceptable attribute values, but it gets hairy if
multiple combinations of such values are acceptable, and the server would
have to select which combination to return or even return all.
Therefore, we won't have the equivalent
of warnings as it would require attribute mutation.

2) Someone else (I forgot whom and could
not find it in the minutes) indicated that a clock skew between client
and server could result in problems if mutation is not allowed. The example
was a client setting the Activation Date to its value of the current date+time,
but the server failing the request because a skew causes backdating and
the server cannot mutate the attribute to its current date+time. However,
the spec does not require the server to fail a request due to backdating
of Activation Date: it is a server-specific policy decision how to handle
it (this also applies to Deactivation Date). I assume that most implementation
will at least allow a certain skew. But the better way to do this is for
the client to call Activate() which will cause the Activation Date to be
set by the server to its current date+time.
Therefore, clock skew is tolerated and
does not require attribute mutation for operations to succeed. There are
details in the Time Stamp section 6.5.

Regards,
-Robert

Robert Haas/Zurich/IBM wrote on 08/12/2009 07:04:35
PM:

> 
> Re: [kmip] Mutating attributes  
> 
> Robert Haas 
> 
> to:
> 
> Marcus Streets
> 
> 08/12/2009 07:04 PM
> 
> Cc:
> 
> "kmip@lists.oasis-open.org"
> 
> We seem to have reached consensus on this topic. To be sure, I 
> suggest to have a voice vote on the call tomorrow. The proposal 
> would be as follows:
> 
> The descriptions of the Template-Attribute returned in operation 
> responses will be changed from:
> 
> " A list of attributes with values that the key management server
> chose differently from those specified in the request (either 
> explicitly or via template). Only those attributes that were 
> specified in the request and were set to different values by the 
> server are included here"
> 
> to
> 
> "A list of attributes with values that the key management server
has
> set implicitly as a result of the operation. It is optional for the
> server to return such a list."
> 
> In addition, text will be changed so that errors are returned 
> instead of mutated attributes.
> 
> Regards,
> -Robert
> 
> Marcus Streets <Marcus.Streets@thales-esecurity.com> wrote on
08/06/
> 2009 01:26:00 PM:
> 
> > [image removed] 
> > 
> > [kmip] Mutating attributes
> > 
> > Marcus Streets 
> > 
> > to:
> > 
> > kmip@lists.oasis-open.org
> > 
> > 08/06/2009 01:26 PM
> > 
> > 
> > The only use case I have for this is to allow the server to allocate
a
> > lower use limit than was requested.
> > 
> > However, I do not have any definite proof that this will be a
problem in
> > practice, and I am not going to be able to gather that in a timely
manner.
> > 
> > Therefore, in order to ensure we move forward and provided that
we leave
> > space in the standard that will allow us to put this in in version
2 if
> > it turns out to be necessary - I am happy we drop mutation from
version 1.
> > 
> > We can therefore close this issue.
> > 
> > Apologies for taking so long.
> > 
> > -- 
> > Marcus Streets
> > Security Standards Officer
> > 
> > THALES Information Systems Security
> > nCipher product line
> > 
> > ------------------------------------------------------
> > T:  +44 (0) 1223 723613 (Direct)
> > F:  +44 (0) 1223 723601
> > E:  Marcus.Streets@thales-esecurity.com
> > W:  www.thalesgroup.com/iss
> > 
> > ---------------------------------------------------------------------
> > 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
> >