Hi Robert,
The Cryptographic usages changes collide slightly with my proposals for changes to support Financial use cases: we’ll ultimately need to merge the two sets.
I’ve certainly added additional specialization where it demonstrably improves security such as translation. I had considered that certain subtleties would
be accommodated by combining a usage permission with a key role. Of course it may be necessary to add non-financial roles to go down this path but ‘DEK’ and ‘KEK’ cover an awful lot of bases.
Also, as I mentioned on the call we’ve pretty much run out of room on the cryptographic usage mask. Adding these specializations basically forces us to widen
the field and therefore change the encoding. We probably need a vote to decide whether it is just this field or multiple ones that need to be widened.
Regards,
Jon
From: Robert Haas [mailto:rha@zurich.ibm.com]
Sent: 16 July 2009 14:11
To: kmip@lists.oasis-open.org
Subject: [kmip] KMIP Wrapping, Crypto Usage Mask, and Template fixes
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.