Re: [kmip] Cryptographic Usage Mask

[Tim Hudson <tjh@cryptsoft.com>]

On 10/04/2014 7:45 AM, Saikat Saha wrote:
> This suggests a KMIP server should not:
> -  In the definition of Secret Data (2.2.7), it says Secret Data is "a
shared secret value that is not a key or certificate (e.g. a password)."
> In the description of Cryptographic Usage Mask (section 3.19), it says
"The Cryptographic Usage Mask defines the cryptographic usage of a key".
> - The values in the bit mask do not correspond to non-key (e.g.
password) use cases. Values such as Encrypt, Sign, Derive Key, etc would
not be valid for a password.

Responding just to the second point within Saikat's email:

The suggestion above that none of the Cryptographic Usage Mask values
apply to Secret Data items is incorrect - and directly contradicted by
the specification text - which can be seen by looking at the Derive Key
operation which can result in Symmetric Key or Secret Data managed
objects as the result.

If you read this statement in Derive Key:

"The request SHALL only apply to Managed Cryptographic Objects that have
the Derive Key bit set in the Cryptographic Usage Mask attribute of the
specified Managed Object (i.e., are able to be used for key derivation)."

Following the logic chain:
1) The Derive Key bit of the Cryptographic Usage Mask means that a
Managed Cryptographic Object can be used in the Derive Key operation
2) The Derive Key operation allows Secret Data items as inputs and
derives keys from those inputs which can result in Secret Data items
(it does allow other inputs and outputs but the context here is to just
show that it is explicit that key derivation on secret data objects is
defined)

It makes it very clear that setting a Cryptographic Usage Mask of Derive
Key against a Secret Data managed object is entirely expected.
There are also multiple references to this within the description of
Derive Key.

I believe this counters the suggestion that the specification did not
intend for the Cryptographic Usage Mask to be a valid attribute for
Secret Data managed objects.
I do agree we have some relatively loose wording around "key" in a few
places within the specification - but that it is clear from the context
when referring to particular managed object types when we reference the
defined terms.

Tim.