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

[John Leiseboer <jl@quintessencelabs.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...).
> 
Tim responded:
> 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).
I think it would be more accurate to say that there was agreement to proceed with development of a proposal to include cryptographic services (and a number of items) in KMIP 1.2. There's a lot of work required to go from agreement to work on the proposal, to agreeing to include the output of the proposal (use cases, spec changes, usage guide material, test cases, etc.) in 1.2.

I note that we also agreed at the face to face to develop use cases for cryptographic services. I believe that the streaming use cases I developed address some of the uses for "get random". Bob submitted a draft use case document for crypto services in the cloud, and use of "get random" for "attested get".

As we agreed in the February face to face, we should first develop the use cases, then work on the detail. The only mature use case related to crypto services at the moment is my own streaming key delivery, and the current proposal fails to satisfy that use case. With due respect to Bob, his two use cases are not nearly developed enough to allow us to proceed with a detailed cryptographic services proposal. (More on this below.)

I made an attempt to list some of the use cases and usages of "get random" in my comparison document of a few weeks back. I'll be the first to admit that it is not a suitable replacement for a use case document. But even so, in the absence of anything else, it's the best we have.

> 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.

I propose that we have a bit of a breather, and reconsider what we're trying to do with crypto services. In particular, I'd like to break it up into at least two different proposals: 1) "get random", and 2) "crypto services" (such as encrypt, decrypt, sign, verify, etc.). For each of these I propose that we develop proper use cases. During use case review, we can decide what is in scope or out of scope. As Tim says, the Cryptsoft crypto proposal has changed significantly from the one presented at the face to face. I would say that this is a direct consequence of not having an agreed set of use cases. Those of us who are engineers on the TC will understand very well that is not possible to design to a moving target. I don't know about others on the TC, but I certainly haven't seen much open discussion on individual's use cases. Let's have the use cases formally written down so that we are all working from the same source of requirements.

I fully understand the urgency of some TC members in locking down a crypto services proposal. But we do need to do this properly. I have been involved in the development of many products and a few standards over the last 35 years - most of them involving network protocols and many involving security: from "trivial" single user systems, through to very complex military systems. In my experience, the most difficult designs to get right are those involving networks, shared services, and security. KMIP crypto services checks all these boxes.

Think about Bob's cloud crypto use case (even incomplete as it is). A server, operated by a third party, providing cryptographic services over a network to potentially many clients. Potentially the client mix includes malicious and/or erroneous implementations. Almost certainly, isolation between clients will be a requirement, as will logging, auditing, active management of operations, control of key material usage, identification of and response to compromise of key material, systems, and/or communications. Is the current crypto services proposal intended to address this usage? If so, is it good enough? Is this something that we want to include in KMIP?

> 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
> 

Regards,
John