Re: [kmip] More on Clarification of Cryptographic Parameters - Usage Guide

[Tim Hudson <tjh@cryptsoft.com>]

Respectfully John, the behaviour in the specification drafts is the behaviour which was discussed and balloted by the technical committee.

For those who have forgotten the details refer to https://www.oasis-open.org/apps/org/workgroup/kmip/ballot.php?id=2380 which was "Do you approve the proposal to support cryptographic services in KMIP, including changes to the KMIP Specification V1.2 and associated profile, as described in “Cryptographic_Services_wd11.pdf” posted 20-March-2013 by Tim Hudson?" and note that in each place the referenced document explicitly stated:

"If omitted then the Cryptographic Parameters associated with the Managed Cryptographic Object with the lowest Attribute Index SHALL be used. If there are no Cryptographic Parameters associated with the Managed Cryptographic Object and the algorithm requires parameters then the operation  SHALL return with a Result Status of Operation Failed"

You opposed that approach over the last year and opposed that ballot (as is your right). I'm not proposing anything here - simply pointing out that your discussion conflicts with what has been balloted (a full majority voted for the proposal) and as such you need to seek support from others if you want the technical committee to make that sort of change in direction.

Although there are merits in your arguments in certain contexts, that particular sort of behaviour belongs in a profile - something which to date you haven't proposed and have also asserted (incorrectly) isn't technically possible.

You can (as can any member) elect to not implement the aspects of the specification that you feel don't meet the needs of your customers. You can also elect which profiles to support and not support. One of the many reasons why profiles are layered with a relatively minimal base is so that this can occur.

And for reference for those who have not been involved in the interop testing: the testing of the cryptographic services operations between the vendors who support those operations went smoothly and no issues in relation to Cryptographic Parameters were raised.

If any other vendor supports your position and speaks up then I'll again do a more detailed response on the items you reference to again place them in the proper context and in light of the KMIP approach to these items. But for now, after almost a year of you arguing your position and with no one coming forward to support it, I don't see that repeating that process is a worthwhile exercise.

As you are currently on a leave of absence, we already have a technical committee view point in place that was discussed and balloted and has been accordingly incorporated in the drafts from the co-editors of the specification, perhaps you should author a profile for discussion on your return.

Once you have actually implemented the functionality under discussion here, we would be happy to perform private interoperability testing with you and bring any findings that are relevant back to the technical committee for further discussion.

I fail to see the point of any further discussion at this time without clear indication of a majority support for a change in direction.

Tim.