Re: [kmip] Concerns with Encrypt, Decrypt, Sign and Verify

[Kiran Kumar Thota <kthota@vmware.com>]

Bob,
 Thanks for raising this. I had certain concerns with this too -

Most of the initiatives that we have taken up for 1.2 seem to fall under "out of scope". We need to address these during re-chartering too.

<snip>
Out of scope areas include:

Implementation specific internals of prototypes and products
Multi-vendor Key Management facility mirrors or clusters
Definition of an architectural design for a central enterprise key management or certificate management system other than any necessary models, interfaces and protocols strictly required to support interoperability between Actors in the multi-vendor certificate and key management framework.
Framework interfaces not dedicated to secure key and certificate management
---> Certain areas of functionality related to key management are also outside the scope of this technical committee, in particular registration of clients, server-to-server communication and key migration. <-----
Bindings other than tag-length-value wire protocol and XSD-based encodings.
</snip>

Thanks,
Kiran

----- Original Message -----
> From: "Robert Lockhart" <Robert.Lockhart@thalesesec.com>
> To: "KMIP Technical Committee" <kmip@lists.oasis-open.org>
> Sent: Tuesday, November 13, 2012 9:05:23 PM
> Subject: [kmip] Concerns with Encrypt, Decrypt, Sign and Verify
> 
> 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.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: kmip-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: kmip-help@lists.oasis-open.org
> 
>