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

[Tim Hudson <tjh@cryptsoft.com>]

On 15/11/2012 08:36, John Leiseboer wrote:

As Tim says, the Cryptsoft crypto proposal has changed significantly from the one presented at the face to face.

The proposal has changed because of feedback from multiple technical committee members wanting additional functionality and it has been reviewed by those folks who have been participating in its development which is exactly how proposals are meant to work within the TC. That cooperative feedback and iterative cycle then bringing back to the wider group is essential how KMIP has been developed. We don't believe in developing proposals in isolation or your end up with the situation of a vendor having done a substantial body of work to propose something which is of no interest to the rest of the group.

If you want to add capability to KMIP which is not well understood then we have agreed as a group that use cases make sense to define to reach a common understanding where variations exist. We also discussed in the face to face that for something like adding cryptographic operations into KMIP the concepts were well understood and that describing a set of use cases of the form "a-client-wants-to-{encrypt,decrypt,sign,verify,mac,etc}" was an unnecessary exercise. For the QKD-specific context that certainly was needed as your descriptions simply didn't make sense to the wider group and Bob also offered to show the context of usage within a cloud environment but that was more from the perspective of showing where the two areas can overlap and certainly not as a prerequisite for bringing this proposal forward and to also work with Kelly on the device attestation mapping. That was discussed. The path forward was agreed.

At this stage it is pretty clear to me that you are fundamentally opposed to the proposal and I assume that it means that QLabs will not be implementing it going forward assuming the majority of the TC votes to accept and that the list of supporting vendors drops to six from seven and as always that's your choice to make.

However raising "security issues" which have nothing to do with this particular proposal and are sufficient generic and nebulous to apply to all of KMIP is simply a delaying tactic.
Nothing in the document you wrote is specific to the cryptographic services proposal.

If the group as a whole feels the scope of the proposal is too wide then we will take that feedback on board - however to date the opposite of that has been the direct feedback - with additional capability being requested by multiple vendors.

Keep in mind that a substantial portion of existing vendor products have cryptographic capability built in - it is simply either only in the vendor proprietary protocols or implemented as vendor specific KMIP extensions. What we have proposed is to actually have a standard way of representing capability for which there is clear demand (vendors don't generally add capability for which there is no market demand).

If you have substantial support from other vendors within the KMIP TC for the views you have expressed then I'd like to hear from them as well.

The entire group is well aware of your views on the topic and repeating the previous discussions simply is not a productive use of time in my view.

Tim.