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

[John Leiseboer <JL@quintessencelabs.com>]

Tim,

 

In your previous arguments – the ones that perhaps swayed people to vote in favour of the crypto operations proposal – you very strongly asserted that your proposal was strictly in line with the existing “model” for Crypto Parameters. The Usage Guide text going all the way back to 1.0 clearly shows this to be a false assertion. It is possible that the TC may have been inadvertently mislead to vote in favour of the proposal.

 

Quite independently of the merits of the changes that I propose, they are entirely consistent with CP behaviour for key wrapping – the closest thing we already have to crypto operations in the standard. It is your proposal that is inconsistent and which I believe needs to be corrected. We continue to correct errors in the standard over time. This sometimes requires deprecation of functionality. We have an opportunity to get this right now without requiring future deprecation to fix this mistake. The purpose of review is to identify errors – no matter how small or large. I am not convinced that we should “rubber-stamp” bad requirements into the standard because of a vote based on misinformation.

 

Some of your points require comment:

 

> 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

The test cases do not exercise the functionality under question. In fact the test cases exercise a very limited amount of CP functionality. Stating that interop participants raised no issues for functionality that was not tested as an argument to not fix the CP behaviour in the crypto operations is misleading as well as illogical.

 

> …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"
This has absolutely nothing to do with my proposal. I have no objection to these requirements. They are not modified by my proposal. This is a red herring. You are diverting attention away from the issue: conflicting Crypto Parameters.

 

> a full majority voted for the proposal

Yes indeed: 51% of eligible voters did vote in favour. The remaining 49% voted against or did not vote at all.

 

> that particular sort of behaviour belongs in a profile - something which to date you … have also asserted (incorrectly) isn't technically possible

Are you saying that a profile can specify behaviour that is disallowed by the standard; e.g. if the standard says, “behaviour SHALL be x”, then a KMIP conformant profile can say, “behaviour SHALL NOT be x”? Or in the context of crypto parameters, “Crypto parameters that conflict with associated crypto parameters SHALL take precedence” – effectively what you have proposed for crypto operations, can be changed in a profile to say, “Crypto parameters that conflict with associated crypto parameters SHALL result in a FAIL response”. That’s dangerous ground to tread for a standard with an “I” for interoperability in its name. It is certainly not something that I have ever seen in the hundreds of standards I have worked with in my 35 years of developing and/or implementing standards.

 

John

 

From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Tim Hudson
Sent: Friday, 26 July 2013 9:00 AM
To: kmip@lists.oasis-open.org
Subject: Re: [kmip] More on Clarification of Cryptographic Parameters - Usage Guide

 

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.