Re: [kmip] Groups - CryptoParamsEnforcement uploaded

[Tim Hudson <tjh@cryptsoft.com>]

On 22/07/2013 8:30 AM, John Leiseboer wrote:
> All profiles must comply with the specification.
> They are meant to narrow behaviour of an implementation,
> not specify non-compliant alternative behaviour.

John, I think you misunderstand the point of the profiles - a profile
can specify behaviour that is not in the base specification - that is
the purpose of a profile. A profile can add, remove, or modify behaviours.

Technically everything in a profile is "non-compliant" with the
specification or there would be little point in having a profile if it
actually did nothing beyond what was in the specification. In almost all
cases, it is a deliberate narrowing of specification conformant options,
and that narrowing of allowed behaviour is by definition non-conformant.

Profiles themselves contain the details as to what conformance to a
particular profile means - and it is the conformance clauses (in each
profile document) which dictates conformance to a profile.

Back when we as a group discussed the whole concept of profiles prior to
KMIP 1.0 it was all about keeping the specification as generic as
possible and placing all the items where varying behaviours might make
sense into one or more profile documents. There was also the expectation
that other groups (non-KMIP, and also non-OASIS) would define profiles
and they would quite reasonably alter fundamental behaviours where those
behaviours did not meet the other groups’ requirements. We hoped we had
made things sufficiently generic that others would not need to state
radically different behaviours - but we simply didn't know what the
outcome was going to be.

There is nothing stopping you defining a profile which mandates servers
and clients behave in the manner described. In that profile you could
state something like the following (by way of an example):

Cryptographic Parameters Enforcement Profile

a) if a client provides a Cryptographic Parameters value in the
operations (list the operations here) that is not in the list of
Cryptographic Parameters associated with the managed object being used
in those operations then the operation should be denied.

b) it is mandatory to specify the Cryptographic Parameters for managed
objects that will be used in the operations (list the operations here)

There is nothing that would preclude you from doing exactly this in a
profile. You could even have variants which preclude the use of block
cipher modes you've raised concerns with like ECB. Again it is up to the
profile to specify its own conformance requirements.

The exact wording and the other items required to make this a profile
are an exercise you would need to go through in drafting a profile
proposal. That is something we might support ourselves depending on
market demand.

Tim.