Re: [kmip] Groups - kmip-cs-profile-v1.0-wd01-review.doc uploaded

[Tim Hudson <tjh@cryptsoft.com>]

Note: conformance is the term to be using - not compliance - but that is an entirely separate topic.

I'd reword your example below to make it clearer - an implementation that depends on behaviours which are not actually specified in the standard is (by definition) non-conforming with respect to the standard. And again rewording your example in another different manner - if you have a dependency on a behaviour which the standard does not mandate then you will by definition not work against a strictly conforming KMIP implementation that does not implement such a non-mandated behaviour.

Such an implementation may however be conforming to a profile which states a specific set of behaviours in its conformance statements. Note that in OASIS terms all the produced documents are standards.

For example, you could define a "(QLabs) Restricted Mode Encryption Server Profile" in which you state in the conformance clauses that the server must enforce that the cryptographic parameters if provided by the client must match one of the cryptographic parameters in the associated attributes for the managed objects that the encryption operation references. I would suggest that the actual formal wording for the conformance clause is something you would want to model off the approach being used in the current set of profiles but there is no requirement to do so - as long as the profile is acceptable to the majority of technical committee members and you can get the required three statements of use it can move through the OASIS process independent of the other documents. Alternatively you can publish an entirely non-OASIS, non-official, vendor-specific profile as previously discussed.

Such a new profile may receive support from other TC members or perhaps may only be relevant to your customers.
Other vendors may propose profiles with entirely different behaviours specified. Both of which can provide clear conformance statements as claims of conformance in the KMIP technical committee are (from KMIP 1.1 onwards) contained within the profiles.

Which profiles end up being supported ultimately is simply a reflection of market demand and in this round of profiles we have a number which are based on shipping generally available product - that list of profiles is something which I for one anticipate will continue to expand given the wave of adoption of KMIP in the market - and profiles will be developed independent of the protocol specification version (covering multiple versions as makes sense).

There are lots of areas within KMIP where there is more than one (reasonable) view on how things should be handled - and in those areas where a consensus cannot be reached on a single approach items are left generic - and handled generally "by server policy". The profiles are the focus for the specific flows and dependencies on such behaviours. We have interoperability - but we do not have a single fixed policy that all vendors must implement - that would require all security products to have a single view and single model for security - and that just hasn't happened.

I know you've expressed frustration that such behaviours are not locked down - but the specification itself is not right place for handling those issues - profiles are the mechanism for that.

Hopefully this fairly lengthy reply and exchange helps clarify why KMIP is the way it is.

Tim.

On 28/06/2013 7:36 PM, John Leiseboer wrote:

Okay, that clarifies it. A client performing, for example, an Encrypt operation, can force the server to perform the operation using a mode or padding method that is not associated with the managed key. This behaviour can be modified by policy (e.g. if you only want Encrypt operations to be performed using mode and/or padding managed by the server), but if so, the implementation will be non-compliant.

 

Thanks,

John

 

From: Tim Hudson [mailto:tjh@cryptsoft.com]
Sent: Friday, 28 June 2013 5:41 PM
To: John Leiseboer
Cc: kmip@lists.oasis-open.org
Subject: Re: [kmip] Groups - kmip-cs-profile-v1.0-wd01-review.doc uploaded

 

On 28/06/2013 4:09 PM, John Leiseboer wrote:

Thanks for the response Tim.

 

I still have a question about BCM and padding. This is an interop question, not an attempt to reopen old debate about the merits of the cryptographic operations. I accept that these attributes are modifiable by a client. But the Encrypt and Decrypt operations are not modifying them. Can these operations temporarily override the BCM and padding rules associated with a key? Or should/must the server return an error if a client requests BCM/Padding that is not defined for the key?

Quoting the specification (using Encrypt as the example):

"The Cryptographic Parameters (Block Cipher Mode, Padding Method, RandomIV) corresponding to the particular encryption method requested. 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."

Stating it differently since it seems your email indicates that style of text used throughout the specification text is (in your view) unclear:
    use the value from the message if it is present;
    otherwise use the lowest index value from the associated attributes for the object;
    if no parameters and parameters are required then this is an error.

At no point within the specification of those operations is there any requirement stated for a server to "match" the requested parameters against what may or may not be associated with the object. That was a deliberate choice in the specification of those operations and discussed when the draft was circulated almost a year ago and on each subsequent version and discussion.

A server of course may elect to implement whatever policy it wants for handling this - however that would be outside the base specification - and may not support clients that depend on this behaviour. The right place and mechanism for defining dependencies on behaviours and subsets where the specification allows a range of options is in a profile - and it would be interesting to work through defining a profile which matches what you have described - however such things do not (by consensus) belong within the specification itself.

Tim.