KMIP Wrapping, Crypto Usage Mask, and Template fixes

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

Hi,
While going over the proposed editorial
changes from Elaine and Judy, some more changes came up that I'd like to
expose to the group before committing them. Please take a look and let
me know if you have comments/suggestions.
Thanks,
-Robert




1) Wrapping (Sec 2.1.5): at the moment,
the spec defines in an exhaustive fashion the following "wrapping
methods", and allows to specify up to two keys to be used in the wrapping/unwrapping
process (one for encryption and authenticated encryption, the other one
for MAC'ing/signing):
- encrypt only (including authenticated
encryption with a single key)
- MAC/sign only
- encrypt then MAC/sign
- MAC/sign then encrypt
- TR-31
- extensions

However:
- "MAC/sign only" does not
really qualify as "wrapping" as the key stays in the clear.
- "sign then encrypt" is not
secure.
- wrapping with public keys can easily
lead to security problems.

There are legacy reasons why we probably
cannot exclude the above from the spec. But should we consider only making
a secure subset mandatory for servers to support (such as symmetric-key
authenticated encryption) ?


2) Crypto Usage Mask (Sec 3.12 and 9.1.3.3.1):
at the moment, the spec defines Wrap/Unwrap for key encipherment/decipherment
purposes (as opposed to Encrypt/Decrypt and Sign/Verify that are meant
to apply on data and not on keys).

Should we refine the usage further and
possibly define the following instead of Wrap and Unwrap?
- Encrypt for Wrap (EW)
- Decrypt for Unwrap (EU)
- MAC/sign Generate for Wrap (MW)
- MAC/sign Verify for Unwrap (MU)

In that case, whenever a client requests
a Key Block of a key that has to be wrapped (by specifying a Key Wrapping
Specification in the Get request), the server must check that the Crypto
Usage Mask of the keys used for wrapping have the EW bit and the MW bit
on, respectively. Similarly, the client must ensure before it unwraps a
key that the Crypto Usage Mask of the keys (specified in the Key Wrapping
Data part of the Key Block) used for unwrapping have the EU bit and the
MU bit on, respectively.

The other existing usages (Encrypt/Decrypt,
Sign/Verify) would therefore solely apply to data. For instance, if a key
can be used to encrypt both data and keys, then it must have both bits
on: EW and "Encrypt".

Note that a key that is used for "encrypt-only"
wrapping using authenticated encryption (same key used for encryption and
authentication) should have both EW and MW bits on. For unwrapping, it
should have EU and MU bits on.

What would be the Crypto Usage Mask
of a key used for wrapping/unwrapping according to the TR-31 method?


3) Crypto Usage Mask: at the moment,
the spec defines "MAC" and "MAC Verify". Although it
does not seem to make much sense to restrict the usage of a key to only
generate MACs (and not allow to verify them), it would be cleaner to specify
instead the following bits separately:
- MAC Generate
- MAC Verify
A key used to generate MACs would therefore
have both bits on (MAC Generate and MAC Verify), whereas a key used solely
to verify MACs would only have that bit on only.


4)  Crypto Usage Mask:: "Export"
is not defined at all. We should specify this.


5) Templates (Sec 2.2.6): at the moment,
Templates are inconsistently defined in the spec: it says that Templates
have a Name attribute that applies to the Template itself (i.e., the Name
is not given to objects created from that Template). However, in Sec 2.1.8,
the spec still refers to a "Template Name" string, distinct form
the Name attribute of the Template. This should be made consistent and
always use the Name attribute.