Concerns with Encrypt, Decrypt, Sign and Verify

["Lockhart, Robert" <Robert.Lockhart@thalesesec.com>]

After going through the specifics of the Encrypt, Decrypt, Sign and Verify proposal, I have a concern that we are trying to bite off more than KMIP should be attempting at this point.

There are several reasons for this at this point in time as listed below:

 1.  The scope of KMIP specifically calls out key management related operations and to therefore to include generic crypto operations that focus on key use may be considered as out of scope for the current protocol.  If we want to expand the functionality to include crypto API type functions this should be part of our re-scoping effort prior to inclusion in the specification.*
 2.  If we were to agree that the scope of KMIP does already include or should be expanded to include these types of generic crypto operations then we would need to ensure we do not confuse the market relative to today's existing crypto APIs (e.g. PKCS, JCE, OpenSSL & CAPI, etc...).
Maybe I’m over-reacting and these additions are not intended to cover generic crypto operations but rather just operations necessary to protect keys while under management (encrypt, sign etc.). If so, we need to put specific bounds around these operations so that they relate explicitly to key management as called out in the current Charter. I think we need to always ensure that we don't confuse the market or allow KMIP to become another protocol that no one uses because it is seen as just something else that has to be supported but not fully in the market for its intended purpose of key management.

* The KMIP Charter can be found at: https://www.oasis-open.org/committees/kmip/charter.php

Bob L.

Robert A. (Bob) Lockhart
Chief Solution Architect - Key Management
THALES e-Security, Inc.