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

[Tim Hudson <tjh@cryptsoft.com>]

On 14/11/2012 15:05, Lockhart, Robert wrote:
> 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...).

We have already agreed that the scope for KMIP 1.2 will include the
cryptographic services (and a number of other items) and that we will
alter the charter if required to enable that (which I've addressed in
the earlier email today). We received commitment in principle to
implementation of the cryptographic services from seven vendors - but of
course that commitment does not include implementing everything in the
scope - we fully expect each vendor to select the portion of the
functionality which matches their anticipated market needs. As a vendor
we (Cryptsoft) have committed to implementing the entire proposal and
performing interoperability testing with other vendors following our
usual strategy.

Your reference to PKCS#11 (assuming that's the particular PKCS you were
referring to) and JCE and OpenSSL and CryptoAPI are rather orthogonal to
the current discussion - those are all cryptographic APIs and not wire
protocol formats so there is simply little scope for confusion there in
the market. If KMIP were to put an API within scope and document that
then I too would share your concern about potential confusion - but
there are ways to address that.

As it stands KMIP does not mandate or attempt to offer an API for
developers - rendering I think your expressed concern as moot.

We do also have a range of SDKs which offer those APIs to developers -
as it makes sense to enable existing application integrations to take
advantage of key management functionality offered by vendors who support
KMIP - but that is something outside the scope of KMIP itself. Other
vendors also offer additional APIs - each vendor taking the approach
they feel best meets the needs of their customer base. Once
cryptographic services are implemented then a broader range of
capability is possible for those sorts of API integrations.

The proposal is broader than what we had originally started out with -
but that has been based on direct feedback from other TC members - it
seems everyone wants just that little bit extra to support some use case
of relevance to them.

That leads to the following two questions
a) are you still committed in principle to implementing the
cryptographic services (or a subset thereof)
b) do you have any specific feedback on the proposal itself beyond the
scope of the operations contained in it

Thanks,
Tim.