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: RE: [kmip] KMIP Wrapping, Crypto Usage Mask, and Template fixes

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.






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


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.

nCipher Corporation Limited is incorporated in England and Wales with company registration number 3169278. Its registered office is located at Jupiter House, Station Road, Cambridge, Cambs, CB1 2JD.

The information contained in this e-mail is confidential. It may also be privileged. It is only intended for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee or the intended addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error please delete it (and all copies) from your system, please also inform us immediately on +44 (0)1223 723600 or email sales@ncipher.com. Commercial matters detailed or referred to in this e-mail are subject to a written contract signed for and on behalf of nCipher Corporation Limited.

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