OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


On 4/07/2013 10:03 AM, John Leiseboer wrote:

On Thursday, 4 July 2013 9:48 AM (AEST) Tim Hudson wrote:

On 4/07/2013 9:26 AM, John Leiseboer wrote:

I think I have a solution for the Multiple Cryptographic Parameters issue.

and I'm still waiting to see any response from others on the topic indicating there is support for radically changing the specification in this area.

And I’m still waiting to see any response from others on the topic indicating there is no support for clarifying the intent behind multiple crypto parameters. My count at the moment is: 1 for change, 1 for no change.

You are grossly exaggerating when you say this is a radical change. This is simply not true. Minimal change is Usage Guide text to provide guidance. I would prefer to see more change than this, but even that would not be radical by any stretch of the imagination.

How about we wait for comments from others? Can we at least agree on that?


Proposals for change require support - and I see no support being expressed for this - as silence should never be taken as support - which is why I too have been asking that others speak up if they do indeed support the concept (and private notes off list don't count in doing this - although the notes from those who have privately expressed they don't support this are appreciated they don't help you).

The change is a radical shift in how KMIP approaches this item conceptually - and it would be a fundamental shift after three years of the specification being out there - and the two years prior to the specification moving into OASIS - and driven not by any real world stated interoperability issue. I think we at Cryptsoft are in a much better position to be able to determine the actual impact of what proposed changes would have than most others in the KMIP TC given our depth of  implementations and deployment of KMIP technology. How you judge that opinion and whether you value that opinion or not is entirely up to you.

You raised this as a major security issue that absolutely must be dealt with - which it simply isn't - and to now suggest that just adding some optional text in the usage guide is the solution is something I don't follow the logic here.

However I do also agree that this topic should remain left as-is until others speak up in support of it to indicate there is at least enough support to warrant discussing it further.

Tim.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]