RE: [kmip] Groups - CryptoParamsEnforcement uploaded

[John Leiseboer <JL@quintessencelabs.com>]

On Friday, 12 July 2013 6:17 PM AEST, Tim Hudson wrote

>Just to make it abundantly clear - this proposal is suggesting text
>which directly conflicts with an already accepted and balloted item
>which has been included in the specification working drafts. It also

It would be more accurate to say that this is a proposal to amend the draft KMIP specification that amongst other things, incorporates some elements from the balloted item. Normally, group discussion and review is sufficient to incorporate changes and edits into KMIP documents. Just because an item has been agreed at ballot does not mean that it is should not be reviewed, updated and corrected when it makes sense to do so.

I urge all TC members to review the proposal - especially the two examples - and decide whether the behaviour in the proposal or the behaviour defined in the draft specification is better for KMIP.

>conflicts with the stated way things are handled within KMIP for
>Cryptographic Parameters and attempts to enforce a behaviour which
>conflicts with the specification text and the usage guide for all
>existing versions of KMIP.

This is nonsense. The proposal is strictly limited to CP handling for cryptographic operations. Crypto operations were not included in 1.0 and 1.1, and this proposal has absolutely no impact on those specifications.

>It also fundamentally changes the purpose of Cryptographic Parameters
>within the specification.

This is also nonsense. Crypto operations are new to 1.2. The use of crypto parameters with crypto operations is new behaviour in 1.2. The proposal is strictly limited to crypto operations. It has no impact on the use or purpose of crypto parameters anywhere else.

>We also have a clear mechanism defined for handling behaviours that are
>not something that fit within the base specification - and that is one
>of profiles - and that is the right way to address suggestions for
>mandatory behaviour enforcement that are not supported by the TC for
>being in the specification.

All profiles must comply with the specification. They are meant to narrow behaviour of an implementation, not specify non-compliant alternative behaviour. The current use of crypto parameters with crypto operations would require non-compliance with the specification, therefore a profile is not an option. In contrast to this, my proposal supports Tim's preferred behaviour as well as my own without requiring new or different profiles - or a profile that requires server behaviour that is not compliant with the specification.

John