Re: [kmip] KMIP Spec v1.2 wd05: Multiple Cryptographic Parameters for a Single Key

[Tim Hudson <tjh@cryptsoft.com>]

On 2/07/2013 1:39 PM, John Leiseboer wrote:
> No, you misunderstand me. I am not saying there is anything in the
> specification that could be literally interpreted this way.

Then you are applying a new meaning to the word "interpretation" that I
for one am not familiar with. If you were trying to suggest a change to
the specification then please make that clearer - rather than wording
things such that it looks like you think that there is a possible
different interpretation of the existing specification (which is what a
lot of the previous discussions have been about). Suggesting changes at
this late stage seems somewhat strange to me (outside of adding
identifiers and error codes and experiences from interop we should be
complete on KMIP 1.2 updates).

The Usage Guide in 3.22.1 (wd03) shows a clear example where the private
and public keys end up with two Cryptographic Parameters values where
the Padding Method is contained in each and has a different value. That
same example has been in place since the 1.0 version of the document -
look at 3.24.1 - although it is now more verbosely stated in the 1.2
version to match the level of detail used elsewhere in the document -
the example shown however remains unchanged in clearly showing multiple
instances. There never has been an interpretation anything like you've
suggested that I'm aware of - and that is what I was responding to. Now
that you've clarified you didn't actually mean that perhaps the
discussion can be more focused.

You are suggesting that we should look at changing something to make it
incompatible with what has been documented in the usage guide for which
there is no existing specification text to support such a change for
which nothing has been raised in the last three years of interop testing
by any of the vendors involved  - is that correct - or am I misreading
your intent?

We do need more test cases and more interoperability tests - and the
co-editors of the various documents have asked repeatedly throughout the
development of KMIP 1.2 (and 1.1 and 1.0) for more input and
contributions and each time it has essentially come down to the editors
to piece together the content and work with others for review. Now that
we have moved to the XML representation for describing test cases the
barrier for proposing test cases is much lower - anyone who can write
XML can contribute - you no longer require an actual KMIP implementation
to do so.

However as a group we work within the constraints of each contributing
organisation to add to the specification and that mix is what results. I
for one think we have covered off on a substantial body of work and
moved the KMIP specification forward and each version has improved over
the previous thanks to the combined efforts of the technical committee.
We don't always agree. We can always do better - but we also need to be
mindful that as a group we have set the scope by consensus for KMIP 1.2
and there will be another version after KMIP 1.2 (perhaps 1.3, perhaps
2.0 - another topic for group discussion).

Tim.