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" <>
> To: "KMIP Technical Committee" <>
> 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:
> For additional commands, e-mail:
>
>
