RE: [kmip] More on Clarification of Cryptographic Parameters

> insufficient rigour

How many changes did you make to the crypto services profile in the last few weeks? Two new drafts, and a couple of dozen or more editing changes, maybe?

How many people commented publicly? 1

How many commented privately? (3 to me in support of tightening CP behaviour for crypto operations)

How thorough was my review of the CS profile document? Not very. I only looked at the basic symmetric key stuff, and random. My own degree of rigour in the review would be less than 20%, yet I managed to comment on 30-plus issues (ranging from trivial to important, some accepted, some rejected, some totally ignored)

How many people participate in the TC? 40-ish

One person providing on-list comments out of 40-ish members is poor. Given the number of changes that have resulted from my own less than rigorous review, I’d say there’s potential for a lot more to come if we ever take a closer look. So yes, insufficient rigour from individuals such as myself, and the TC as a whole. I wouldn’t say that if the change count was low. The metrics speak for themselves.

> mislead the TC

Inadvertently. I strongly doubt that anyone on the TC would do so on purpose.

> in reality 68% (rounding up - 19 "yes" to 9 "no") of the TC voted for the proposal

I got my numbers from the ballot results page as follows:

37 eligible voters

19/37 (51.4%) voted yes -> 51% (rounded to nearest integer)

9/37 (24.3%) voted no

9/37 (24.3%) did not vote

18/37 (48.6%) voted no, or did not vote -> 49% (rounded to nearest integer)

> If you want to change what has already been balloted then you need to get support from others

That’s what I’m doing. It’s only in the last few weeks that everything (spec, usage guide, profiles, etc.) has started to come together. The test cases in the profiles documents are really useful for identifying issues with old and new functionality. Look at the changes we’re making to clarify State, Protect Stop Date, Process Start Date, additional Cryptographic Parameters (for GCM, CCM, CTR modes), etc. A lot of this is coming from review of the test cases in the profiles documents. Not only are we clarifying and fixing old functionality, we should be ensuring that the new functionality is what we really expect and want it to be.

I think it’s important to get this right before we promote the documents too far. It will make change harder, delay 1.2, and have a bigger impact if we prematurely release the documents.

John

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

On 26/07/2013 1:23 PM, John Leiseboer wrote:

This is an important difference, and one that can be easy to miss when insufficient rigour is applied in proposing and reviewing behaviour.

I don't know about other members of the TC, but I for one find the continued inferences that I've mislead the TC and the statement above that the entire TC has exercised insufficient rigour because we happen to have a different view point both insulting and inappropriate to see in an open discussion such as this.

I admire your passion, but disagree with your entire line of reasoning and arguments on the topic, which frankly are all centred on the one issue where we fundamentally disagree about KMIP.

If you want to change what has already been balloted then you need to get support from others to do so. None has been forthcoming and that really should have made it clear that your view point (on this topic) is not shared.

Correcting your previous statements about the vote in the ballot, in reality 68% (rounding up - 19 "yes" to 9 "no") of the TC voted for the proposal (on an individual basis) and (excluding the organisation which voted both yes and no) 80% of the organisations that cast votes actually voted yes.

Tim.

kmip message