OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: KMIP Wrapping, Crypto Usage Mask, and Template fixes

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.

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

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]