Re: [kmip] Derive Key Operation

[Tim Hudson <tjh@cryptsoft.com>]

On 19/12/2014 12:50 PM, John Leiseboer wrote:
> The standard clearly states that this is required, but then it appears to contradict itself - sort of - in tables 140 and 141 when describing the Derivation Data field.

It doesn't contradict itself at all - something you appear to also be
agreeing with in your choice of wording with the use of "appears" and
"sort of".

Summarising the context:

1) There can be one or two unique identifiers provided in the request -
it is a YES-may-be-repeated parameter.
2) The derivation data can be provided either via a unique identifier
referencing a secret data item (one of those provide in the request) or
by direct value.

The two statements are themselves not contradictory and the combination
makes it clear that you can only use derivation data when you are using
a derivation mechanism that is referencing a unique identifier - that
provides for both statements to remain true and not be contradictory.
That there is an alternate way of sometimes specifying derivation data
doesn't override that one or more unique identifiers are always required.

The "Yes, unless the Unique Identifier of a Secret Data object is
provided" could be reworded to "Yes, but only when the Unique Identifier
of a Secret Data object has not been provided" but without adding
something like "and don't forget this doesn't override all the other
statements within this section" there remains (as always) opportunities
to creatively misread the specification (by ignoring the clear statements).

The whole concept with this operation (which I've raised multiple times
before could do with a pile of test cases and additional vendor
implementation) is that it is always operating on a managed object and
it produced a managed object as the result of the operation. I'd also
like to note that you have argued passionately against the concept of
operations which don't referenced managed objects on multiple occasions
and it seems to me at least that you've shifted to a different view (in
this context).

I've also previously mentioned that Table 156 and 155 (using the
references in the current TC approved version of the KMIP 1.2 - the CS
version) should be listed as one table with the last two items as
required for PBKDF2 and not permitted for the other values - but that is
more of a style issue in terms of how different variations of the same
structure should be handled. Elsewhere we have defined it once and
listed the variations inline.

Also thinking back to the TC meeting this week - you stated your context
for hitting this item was that of PKCS#11 itself and your mapping across
to KMIP - and the C_DeriveKey operation there always mandates a
reference to an object handle within PKCS#11 - so in that context you
always have a unique identifier (equivalent) mapping.

Tim.