OASIS Key Management Interoperability Protocol (KMIP) TC

Submitter's message Updated conformance wording style. Updated test case style. Included test cases for 1.2. Applied new OASIS template.

Note: the byte values for the test data in the Advanced Cryptographic Tests remains to be updated from the placeholder values. -- Tim Hudson Document Name : kmip-cs-profile-v1.0-wd01-review.doc Description Cryptographic Services Profile Download Latest Revision Public Download Link Submitter : Tim Hudson Group : OASIS Key Management Interoperability Protocol (KMIP) TC Folder : Drafts Date submitted : 2013-06-27 07:25:14

KMIP Team,   Section 4.22 of the KMIP spec at http://docs.oasis-open.org/kmip/spec/v1.1/os/kmip-spec-v1.1-os.html#_Toc333494539 doesn’t mention any state restrictions. It’s very unlikely this is an oversight. More likely Get is allowed in any state.   The section 3.22 in the KMIP spec quoted below says "Pre-Active: The object exists but is not yet usable for any cryptographic purpose." Retrieving using Get is not a cryptographic purpose so returning a pre-active key does not violate this. This is reinforced by the text in test 4.1 which says “[being in the compromised state] does not stop a client from being able to add, modify and delete attributes or even get the key (since we assume here that the out-of-band registration has been used to make the server aware of the fact that the client is capable of interpreting the attributes of the key and determining what it is allowed to do with the key).” Emphasis added by me. Therefore it appears it is the client’s responsibility to determine what is allowed to be done with the key based on the attributes returned by the KS/DS.   Test case 3.1.3 at http://docs.oasis-open.org/kmip/testcases/v1.1/cn01/kmip-testcases-v1.1-cn01.html#_Toc333488775 is titled “Test Case: Create / Locate / Get / Destroy”. That sequence of commands is supposed to succeed. Requiring that the Activate command or setting the Activation Date such that the key becomes Active before the Get command is called would cause this test case to fail.     Given above, what is committee members consensus of allowing the “Get” command to retrieve a “Pre-Active” key or Secret Data object?   One view is that precluding Get from retrieving Pre-Active keys does appear to violate spec. Other view is that why would the KMIP server allow to retrieve a key that is in “Pre-active” state. Some real-life customers have proposed that server should not allow clients to retrieve an object in pre-active state.   Would appreciate some feedback from the committee members.   Regards, Saikat   The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.

Saikat,

I agree that the spec is silent about
the consideration of the object's state relative to the Get operation,
and that we have exercised testcases (from the very beginning of the protocol)
that return a key's value despite its state.
(I would also point out that in the
errors for all operations and for the get operation in particular, there
is no reason listed that relates to "key in improper state for operation")
One of the reasons that the server can
get away with this is that we have no idea what the requesting client proposes
to do with the key material, so the server has "plausible deniability".

Since the obtaining of key material
is not what the NIST state model is about, but rather the usage of such
material, I would assert that this question becomes much more pertinent
for the newer cryptographic services addition to the spec.  Where
the server is performing an operation that is supposed to be modulated
by an object's state, then the server should consider the state of the
key and the request being processed and return an error if the request
and the state conflict.  (That's a part of the M in KMIP)  Hmm,
when I go to the spec, I see NO errors returned by any of the new cryptographic
services, so it seems we are missing some needed pieces to answer your
question in this new context.  Why no new error reasons from the new
operations?  I do not think the server has plausible deniability here.

Bruce A Rich
brich at-sign us dot ibm dot com




From:      
  "Saha, Saikat"
<Saikat.Saha@safenet-inc.com>
To:      
  "kmip@lists.oasis-open.org"
<kmip@lists.oasis-open.org>
Date:      
  06/27/2013 11:52 AM
Subject:    
    [kmip] Specification
clarification in regard to managed object retrieval
Sent by:    
    <kmip@lists.oasis-open.org>




KMIP Team,
 
Section 4.22 of the KMIP spec at http://docs.oasis-open.org/kmip/spec/v1.1/os/kmip-spec-v1.1-os.html#_Toc333494539
doesn’t mention any state restrictions. It’s very unlikely this is an
oversight. More likely Get is allowed in any state.
 
The section 3.22 in the KMIP spec quoted
below says "Pre-Active: The object exists but is not yet usable for
any cryptographic purpose." Retrieving using Get is not a cryptographic
purpose so returning a pre-active key does not violate this. This is reinforced
by the text in test 4.1 which says “[being in the compromised state] does
not stop a client from being able to add, modify and delete attributes
or even get the key (since we assume here that the out-of-band registration
has been used to make the server aware of the fact that the client is capable
of interpreting the attributes of the key and determining what it is allowed
to do with the key).” Emphasis added by me. Therefore it appears it is
the client’s responsibility to determine what is allowed to be done with
the key based on the attributes returned by the KS/DS.
 
Test case 3.1.3 at http://docs.oasis-open.org/kmip/testcases/v1.1/cn01/kmip-testcases-v1.1-cn01.html#_Toc333488775
is titled “Test Case: Create / Locate / Get / Destroy”. That sequence
of commands is supposed to succeed. Requiring that the Activate command
or setting the Activation Date such that the key becomes Active before
the Get command is called would cause this test case to fail.
 
 
Given above, what is committee
members consensus of allowing the “Get” command to retrieve a “Pre-Active”
key or Secret Data object?
 
One view is that precluding
Get from retrieving Pre-Active keys does appear to violate spec.
Other view is that
why would the KMIP server allow to retrieve a key that is in “Pre-active”
state. Some real-life customers have proposed that server should not allow
clients to retrieve an object in pre-active state.
 
Would appreciate some feedback
from the committee members.
 
Regards,
Saikat
 
The information contained in this electronic mail transmission

may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.

Some of the states don't say what is allowed or not allowed and leave a lot up to the client to be well behaved. A good example of this is a key in process only state. What it means is that a server can provide the key to the client if it is allowed to normally get it or get it under special circumstances. What the client does with the key after that is up to the client which may not care about FIPS, common criteria, states or other such things. A server has little if any control over what a client does with a key once he gets it. In fact, in most cases today, devices completely ignore state or usage masks and do with the key as they please (most of the storage devices out there come to mind when typing this statement). There is also a fine line of what is vendor specific and what should be in the specification. My personal opinion has always been that if a key is in the pre-active state and it leaves the device where generated, it should be put into an active state prior to register or get functions as some clients as mentioned above don't care about key state and that means that in theory that keys could live their entire life in a pre-active state... Basically this means that a key registered to a server should never be in a pre-active state at all. The servers can't trace the history of a key beyond whomever registered it unless the key has a lot of metadata associated with it when registered. Being my jaded self, I think most clients believe that less is more when creating their own keys and then registering them. It is really up to a vendor to interpret how they want to implement it and we would need to tread lightly here. I have an old email from the folks (Elaine B.) at NIST during the P1619.3 days on this topic and could dig it out for refresher or we could ask the NIST folks for their opinion since I think some of us are concerned more from a FIPS and CC standpoint than others might be. Just my pennies worth, Bob L. Robert A. (Bob) Lockhart Chief Solution Architect - Key Management THALES e-Security, Inc. ________________________________ From: kmip@lists.oasis-open.org [kmip@lists.oasis-open.org] on behalf of Saha, Saikat [Saikat.Saha@safenet-inc.com] Sent: Thursday, June 27, 2013 09:50 To: kmip@lists.oasis-open.org Subject: [kmip] Specification clarification in regard to managed object retrieval KMIP Team, Section 4.22 of the KMIP spec at http://docs.oasis-open.org/kmip/spec/v1.1/os/kmip-spec-v1.1-os.html#_Toc333494539 doesn’t mention any state restrictions. It’s very unlikely this is an oversight. More likely Get is allowed in any state. The section 3.22 in the KMIP spec quoted below says "Pre-Active: The object exists but is not yet usable for any cryptographic purpose." Retrieving using Get is not a cryptographic purpose so returning a pre-active key does not violate this. This is reinforced by the text in test 4.1 which says “[being in the compromised state] does not stop a client from being able to add, modify and delete attributes or even get the key (since we assume here that the out-of-band registration has been used to make the server aware of the fact that the client is capable of interpreting the attributes of the key and determining what it is allowed to do with the key).” Emphasis added by me. Therefore it appears it is the client’s responsibility to determine what is allowed to be done with the key based on the attributes returned by the KS/DS. Test case 3.1.3 at http://docs.oasis-open.org/kmip/testcases/v1.1/cn01/kmip-testcases-v1.1-cn01.html#_Toc333488775 is titled “Test Case: Create / Locate / Get / Destroy”. That sequence of commands is supposed to succeed. Requiring that the Activate command or setting the Activation Date such that the key becomes Active before the Get command is called would cause this test case to fail. Given above, what is committee members consensus of allowing the “Get” command to retrieve a “Pre-Active” key or Secret Data object? One view is that precluding Get from retrieving Pre-Active keys does appear to violate spec. Other view is that why would the KMIP server allow to retrieve a key that is in “Pre-active” state. Some real-life customers have proposed that server should not allow clients to retrieve an object in pre-active state. Would appreciate some feedback from the committee members. Regards, Saikat The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.

Only had time to review through to Section 7. I’ll try to find more time next week for the remainder of the document.   kmip-cs-profile-v1.0-sd01-review.doc   Line 63 "KMIP Baseline Client" should be "KMIP Baseline Server".   Line 67 Which "Mandatory Test Cases" are being referred to? (The tests in Section 4?)   Line 81 Which "Mandatory Test Cases" are being referred to? (The tests in Section 4?)   Line 86 Are these the "Mandatory Test Cases" referred to in lines 67 and 81?   Line 87 This conflicts with lines 78, 79 and 80. Line 87 allows a client to support any one of the test cases; e.g. Create/Encrypt/Destroy, but lines 78-80 require that a client support BOTH Encrypt and Decrypt.   Starting at line 110, Test case 4.1.6, CS-BC-M-6-12 - Encrypt and Decrypt with Known Symmetric Key The block cipher mode is not specified. It should be specified either in the key Registration request, or in both of the Encrypt and Decrypt requests.   For better interoperability coverage, additional tests for at least the following are required:   - Additional block cipher modes. Testing only with the (insecure) ECB mode will not flush out potential implementation mistakes with the various feedback modes. - In conjunction with additional block cipher modes, some different padding methods should be specified. - In conjunction with additional block cipher modes, initialisation vector, counter, and nonce (where applicable) input by the client should be specified. - It is still unclear to me whether Block Cipher Mode and Padding Method attributes specified by the client in Encrypt and Decrypt requests can force the server to override these normally immutable attributes. Some tests illustrating expected behaviour are necessary. - Some error test cases would be useful; e.g. trying to perform an Encrypt operation using the wrong type of managed object; specifying incompatible or conflicting attributes like mode or padding; providing an IV and/or padding method for ECB mode; etc.   Line 117 "KMIP Baseline Client" should be "KMIP Baseline Server".   Line 120 Typo: missing "]"   Line 121 Which "Mandatory Test Cases" are being referred to? (The tests in Section 7?)   Line 134 Typo: missing "]"   Line 135 Which "Mandatory Test Cases" are being referred to? (The tests in Section 7?)   Line 140 Are these the "Mandatory Test Cases" referred to in lines 121 and 135?   Line 141 Does this mean that the vendor decides which test cases are mandatory for the client?   Line 142 This says that the server must support all of the test cases listed. Any suggestions on how to perform these tests, as they require different, incompatible server behaviour? Are you assuming some out of band communication (KMIP extension, non-KMIP, server management channel, human to human, etc.) to set up the server behaviour prior to running the tests in question?   Seed RNG with Server Accept, Seed RNG with Server partial Accept, Seed RNG with Server Ignore, and Seed RNG with Server Deny each return different responses (and presumably invoke different internal server behaviour - although the specification does not require this) for exactly the same request.   If Seed RNG with Server Accept is supported by the server, and performed multiple times, each followed by RNG Retrieve, must each returned random be identical? If not, is it allowed to be identical? If so, under what conditions is it allowed to be identical, or can it be forced to be identical?   John   From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Tim Hudson Sent: Friday, 28 June 2013 12:25 AM To: kmip@lists.oasis-open.org Subject: [kmip] Groups - kmip-cs-profile-v1.0-wd01-review.doc uploaded   Submitter's message Updated conformance wording style. Updated test case style. Included test cases for 1.2. Applied new OASIS template. Note: the byte values for the test data in the "Advanced Cryptographic Tests" remains to be updated from the placeholder values. -- Tim Hudson Document Name : kmip-cs-profile-v1.0-wd01-review.doc Description Cryptographic Services Profile Download Latest Revision Public Download Link Submitter : Tim Hudson Group : OASIS Key Management Interoperability Protocol (KMIP) TC Folder : Drafts Date submitted : 2013-06-27 07:25:14  

On 28/06/2013 12:21 PM, John Leiseboer wrote: Only had time to review through to Section 7. I’ll try to find more time next week for the remainder of the document. Thanks John - appreciate the clear and timely feedback - all the items related to typographic errors and some left over text from the proposal have been corrected. The CS-BC-M-6-12 example has been updated (I pasted in the wrong version) - it has the BCM of ECB as per the other examples. The suggestions for additional test cases have been noted. I'll wait a few days to collate more feedback and then upload a version (wd02) after that unless others indicate they would like that version available sooner. The tests with ids containing -M- are mandatory and ids containing -O- are optional test cases as per the test case naming strategy we used for the previous round of interop test in Dec12/Jan13 - although that wasn't explicitly noted in the document (it is now). That same additional note may need to be applied to the other profile documents but that is more simple editorial changes. Other comments about the operation behaviour were previously addressed (prior to the proposal being balloted for inclusion in the specification) and revisiting that item (yet again) in the profile feedback isn't the right context in my view; however as previously noted in the discussions on the original proposal and in the ballot and repeated here again your concerns about BCM and Padding handling overlook the fact that the Cryptographic Parameters are not immutable (they have simply never been immutable in any version of KMIP) and are also multi-instance and modifiable by the client.  See table 55 Cryptographic Parameters Attribute Rules at Line 607 in the wd06 version of the specification (partially reproduced below): Modifiable by client            Yes Deletable by client             Yes Multiple instances permitted    Yes Feedback at the same level of detail on the other profiles and updated test cases would also be appreciated. Thanks, Tim.

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?   I can see a use case where one client is authorised to manage (modify) key attributes, but another client is only authorised to use (Get, Encrypt, Decrypt, etc.) key material. Should this second client be allowed to force the server to temporarily modify the attributes for Encrypt/Decrypt operations?   John   From: Tim Hudson [mailto:tjh@cryptsoft.com] Sent: Friday, 28 June 2013 3:56 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 12:21 PM, John Leiseboer wrote: Only had time to review through to Section 7. I’ll try to find more time next week for the remainder of the document. Thanks John - appreciate the clear and timely feedback - all the items related to typographic errors and some left over text from the proposal have been corrected. The CS-BC-M-6-12 example has been updated (I pasted in the wrong version) - it has the BCM of ECB as per the other examples. The suggestions for additional test cases have been noted. I'll wait a few days to collate more feedback and then upload a version (wd02) after that unless others indicate they would like that version available sooner. The tests with ids containing -M- are mandatory and ids containing -O- are optional test cases as per the test case naming strategy we used for the previous round of interop test in Dec12/Jan13 - although that wasn't explicitly noted in the document (it is now). That same additional note may need to be applied to the other profile documents but that is more simple editorial changes. Other comments about the operation behaviour were previously addressed (prior to the proposal being balloted for inclusion in the specification) and revisiting that item (yet again) in the profile feedback isn't the right context in my view; however as previously noted in the discussions on the original proposal and in the ballot and repeated here again your concerns about BCM and Padding handling overlook the fact that the Cryptographic Parameters are not immutable (they have simply never been immutable in any version of KMIP) and are also multi-instance and modifiable by the client.  See table 55 "Cryptographic Parameters Attribute Rules" at Line 607 in the wd06 version of the specification (partially reproduced below): Modifiable by client            Yes Deletable by client             Yes Multiple instances permitted    Yes Feedback at the same level of detail on the other profiles and updated test cases would also be appreciated. Thanks, Tim.

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.

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.

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.

Continuing review of kmip-cs-profile-v1.0-sd01-review.doc.   Section 4 All tests start with either registration or creation of a key. This will result in a key that is in the pre-active state. The tests then proceed with Encrypt and Decrypt operations on the pre-active key. Surely the keys should be moved to the active state first. (Noting that the server profile requires that the server conforms with the KMIP Baseline Server Profile (“Client” typo previously commented on, and acknowledged as such), which in turn requires that the server support the State attribute.)   Section 4 Assuming that the crypto operations observe and comply with the value of the key state, and the keys are put into the active state prior to being used, then keys will have to be moved to the deactivated state before being destroyed.   Sections 2, 3 and 4 – Base Cryptographic stuff Is it intended that conformance with this profile simply means that a client can request, and a server can perform, encrypt and decrypt operations using an AES key in ECB mode? If so, then apart from questioning the usefulness of this profile, shouldn’t the profile name be changed to something that better reflects this very limited capability? Perhaps “Basic AES ECB Mode Cryptographic Profile”?   Seriously, shouldn’t these sorts of profiles be more comprehensive in their test coverage? Here is an incomplete dump of some basic things that should be tested for conformance. I stress this is just a quick dump. Other reviewers will undoubtedly identify more.   Correct behaviour when the State attribute for a key is set to different modes; e.g. pre-active: encrypt/decrypt should fail, destroyed: encrypt/decrypt should fail. Correct behaviour for values of Process Start Date and Protect Stop Date; i.e. Encrypt and Decrypt should only work when the dates permit. Correct behaviour with Usage Limits; e.g. server correctly updates Usage Limits Count after Encrypt, server deny Encrypt when Usage Limit Total is reached.   I’m pretty sure that Tim will object to this one (and this should really be discussed at specification level, but it will impact conformance, so I’ll risk raising it here now): Current defined behaviour (I believe) is for Crypto Parameters (such as BCM) defined in the client’s Encrypt/Decrypt request take precedence over the Crypto Parameters managed by the server. I would like to see this changed, such that the client can still request, for example, that ECB mode be used, but if ECB mode is not already defined as a mode for a managed key, that the server deny the Encrypt/Decrypt request; i.e. the Crypto Parameters that are associated with a key become a “white list” of allowed parameters. If the “white list” is empty, then the client can ask for whatever it wants, and if it’s possible, the server complies. But if mode, or padding method, for example is requested that is not on the “white list”, the server denies the operation. So if we can go with this change, then we need to test for conformance.   Structure of tests – Base Crypto profiles. The conformance requirements reference Baseline profiles, and add Encrypt and Decrypt operations as requirements. They also require that the mandatory tests be successful. The mandatory tests include operations such as Create, Register and Destroy. Is it really intended that a Base Crypto Client must support these operations? If yes, that should be stated and not implied by the test cases. If no, and I think a better, more generic approach regardless, then the tests should be reformatted into at least three sections:   Test setup This is where pre-conditions for the test are stated and established; e.g. load keys onto a server; issue credentials for client-server communications; set values of attributes that are relevant to tests, etc.   Test This is where the actual conformance tests are run. No client, and no server, should be required to perform operations that are not explicitly stated in the conformance requirements.   Test teardown This is where all the post processing stuff is performed; e.g. confirm attributes were updated correctly; test keys and other objects are removed from the server, etc.   Section 11 All the 11.x conformance statements: “…for each supported protocol version (major and minor)…”   Can this be clarified please? As Crypto Services are possibly being introduced into KMIP 1.2, I take this to mean that it is not possible to claim conformance to this profile for 1.0 and 1.1. That would mean retrospective changes to earlier released specifications. So can we clarify that this means from KMIP 1.2 going forward?   John   From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of John Leiseboer Sent: Friday, 28 June 2013 12:21 PM To: Tim Hudson; kmip@lists.oasis-open.org Subject: RE: [kmip] Groups - kmip-cs-profile-v1.0-wd01-review.doc uploaded   Only had time to review through to Section 7. I’ll try to find more time next week for the remainder of the document.   kmip-cs-profile-v1.0-sd01-review.doc   Line 63 "KMIP Baseline Client" should be "KMIP Baseline Server".   Line 67 Which "Mandatory Test Cases" are being referred to? (The tests in Section 4?)   Line 81 Which "Mandatory Test Cases" are being referred to? (The tests in Section 4?)   Line 86 Are these the "Mandatory Test Cases" referred to in lines 67 and 81?   Line 87 This conflicts with lines 78, 79 and 80. Line 87 allows a client to support any one of the test cases; e.g. Create/Encrypt/Destroy, but lines 78-80 require that a client support BOTH Encrypt and Decrypt.   Starting at line 110, Test case 4.1.6, CS-BC-M-6-12 - Encrypt and Decrypt with Known Symmetric Key The block cipher mode is not specified. It should be specified either in the key Registration request, or in both of the Encrypt and Decrypt requests.   For better interoperability coverage, additional tests for at least the following are required:   - Additional block cipher modes. Testing only with the (insecure) ECB mode will not flush out potential implementation mistakes with the various feedback modes. - In conjunction with additional block cipher modes, some different padding methods should be specified. - In conjunction with additional block cipher modes, initialisation vector, counter, and nonce (where applicable) input by the client should be specified. - It is still unclear to me whether Block Cipher Mode and Padding Method attributes specified by the client in Encrypt and Decrypt requests can force the server to override these normally immutable attributes. Some tests illustrating expected behaviour are necessary. - Some error test cases would be useful; e.g. trying to perform an Encrypt operation using the wrong type of managed object; specifying incompatible or conflicting attributes like mode or padding; providing an IV and/or padding method for ECB mode; etc.   Line 117 "KMIP Baseline Client" should be "KMIP Baseline Server".   Line 120 Typo: missing "]"   Line 121 Which "Mandatory Test Cases" are being referred to? (The tests in Section 7?)   Line 134 Typo: missing "]"   Line 135 Which "Mandatory Test Cases" are being referred to? (The tests in Section 7?)   Line 140 Are these the "Mandatory Test Cases" referred to in lines 121 and 135?   Line 141 Does this mean that the vendor decides which test cases are mandatory for the client?   Line 142 This says that the server must support all of the test cases listed. Any suggestions on how to perform these tests, as they require different, incompatible server behaviour? Are you assuming some out of band communication (KMIP extension, non-KMIP, server management channel, human to human, etc.) to set up the server behaviour prior to running the tests in question?   Seed RNG with Server Accept, Seed RNG with Server partial Accept, Seed RNG with Server Ignore, and Seed RNG with Server Deny each return different responses (and presumably invoke different internal server behaviour - although the specification does not require this) for exactly the same request.   If Seed RNG with Server Accept is supported by the server, and performed multiple times, each followed by RNG Retrieve, must each returned random be identical? If not, is it allowed to be identical? If so, under what conditions is it allowed to be identical, or can it be forced to be identical?   John   From: kmip@lists.oasis-open.org [ mailto:kmip@lists.oasis-open.org ] On Behalf Of Tim Hudson Sent: Friday, 28 June 2013 12:25 AM To: kmip@lists.oasis-open.org Subject: [kmip] Groups - kmip-cs-profile-v1.0-wd01-review.doc uploaded   Submitter's message Updated conformance wording style. Updated test case style. Included test cases for 1.2. Applied new OASIS template. Note: the byte values for the test data in the "Advanced Cryptographic Tests" remains to be updated from the placeholder values. -- Tim Hudson Document Name : kmip-cs-profile-v1.0-wd01-review.doc Description Cryptographic Services Profile Download Latest Revision Public Download Link Submitter : Tim Hudson Group : OASIS Key Management Interoperability Protocol (KMIP) TC Folder : Drafts Date submitted : 2013-06-27 07:25:14  

Continuing review, kmip-cs-profile-v1.0-wd02-review.doc (note: wd02 now)   The comments below directly address the Base Cryptographic Server profile only, but other profiles in this document share similar issues.   I recommend that the test cases in this profile document be non-normative. My reason for this is that the test cases do not exercise the conformance requirements sufficiently to verify that an implementation is conformant. For example, only 4/15 (27%) operations required by the Base Cryptographic Server conformance requirements are present in the test cases in Section 4.  Required attributes (9/17 – 53%),  and objects (4/6 – 67%) are present more often, but not enough to verify conformance with the requirements. The other profiles in this document have similar problems.   Continuing the theme of test coverage, wd02 has introduced new tests, and changed some old ones. Unfortunately, the additions and changes do not properly address the issues that they were meant to fix. For example: - The addition of an Activation Date does not verify that the server complies with the requirement to support the State attribute. A non-conformant server can pass this test. Tests should be included to verify that Encrypt/Decrypt operations are NOT performed when the key state does not permit it. - Correct handling of Process Start Date and Protect Stop Date are still not verified for the Encrypt and Decrypt operations.   John   From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of John Leiseboer Sent: Friday, 5 July 2013 3:46 PM To: kmip@lists.oasis-open.org Subject: RE: [kmip] Groups - kmip-cs-profile-v1.0-wd01-review.doc uploaded   Continuing review of kmip-cs-profile-v1.0-sd01-review.doc.   Section 4 All tests start with either registration or creation of a key. This will result in a key that is in the pre-active state. The tests then proceed with Encrypt and Decrypt operations on the pre-active key. Surely the keys should be moved to the active state first. (Noting that the server profile requires that the server conforms with the KMIP Baseline Server Profile (“Client” typo previously commented on, and acknowledged as such), which in turn requires that the server support the State attribute.)   Section 4 Assuming that the crypto operations observe and comply with the value of the key state, and the keys are put into the active state prior to being used, then keys will have to be moved to the deactivated state before being destroyed.   Sections 2, 3 and 4 – Base Cryptographic stuff Is it intended that conformance with this profile simply means that a client can request, and a server can perform, encrypt and decrypt operations using an AES key in ECB mode? If so, then apart from questioning the usefulness of this profile, shouldn’t the profile name be changed to something that better reflects this very limited capability? Perhaps “Basic AES ECB Mode Cryptographic Profile”?   Seriously, shouldn’t these sorts of profiles be more comprehensive in their test coverage? Here is an incomplete dump of some basic things that should be tested for conformance. I stress this is just a quick dump. Other reviewers will undoubtedly identify more.   Correct behaviour when the State attribute for a key is set to different modes; e.g. pre-active: encrypt/decrypt should fail, destroyed: encrypt/decrypt should fail. Correct behaviour for values of Process Start Date and Protect Stop Date; i.e. Encrypt and Decrypt should only work when the dates permit. Correct behaviour with Usage Limits; e.g. server correctly updates Usage Limits Count after Encrypt, server deny Encrypt when Usage Limit Total is reached.   I’m pretty sure that Tim will object to this one (and this should really be discussed at specification level, but it will impact conformance, so I’ll risk raising it here now): Current defined behaviour (I believe) is for Crypto Parameters (such as BCM) defined in the client’s Encrypt/Decrypt request take precedence over the Crypto Parameters managed by the server. I would like to see this changed, such that the client can still request, for example, that ECB mode be used, but if ECB mode is not already defined as a mode for a managed key, that the server deny the Encrypt/Decrypt request; i.e. the Crypto Parameters that are associated with a key become a “white list” of allowed parameters. If the “white list” is empty, then the client can ask for whatever it wants, and if it’s possible, the server complies. But if mode, or padding method, for example is requested that is not on the “white list”, the server denies the operation. So if we can go with this change, then we need to test for conformance.   Structure of tests – Base Crypto profiles. The conformance requirements reference Baseline profiles, and add Encrypt and Decrypt operations as requirements. They also require that the mandatory tests be successful. The mandatory tests include operations such as Create, Register and Destroy. Is it really intended that a Base Crypto Client must support these operations? If yes, that should be stated and not implied by the test cases. If no, and I think a better, more generic approach regardless, then the tests should be reformatted into at least three sections:   Test setup This is where pre-conditions for the test are stated and established; e.g. load keys onto a server; issue credentials for client-server communications; set values of attributes that are relevant to tests, etc.   Test This is where the actual conformance tests are run. No client, and no server, should be required to perform operations that are not explicitly stated in the conformance requirements.   Test teardown This is where all the post processing stuff is performed; e.g. confirm attributes were updated correctly; test keys and other objects are removed from the server, etc.   Section 11 All the 11.x conformance statements: “…for each supported protocol version (major and minor)…”   Can this be clarified please? As Crypto Services are possibly being introduced into KMIP 1.2, I take this to mean that it is not possible to claim conformance to this profile for 1.0 and 1.1. That would mean retrospective changes to earlier released specifications. So can we clarify that this means from KMIP 1.2 going forward?   John   From: kmip@lists.oasis-open.org [ mailto:kmip@lists.oasis-open.org ] On Behalf Of John Leiseboer Sent: Friday, 28 June 2013 12:21 PM To: Tim Hudson; kmip@lists.oasis-open.org Subject: RE: [kmip] Groups - kmip-cs-profile-v1.0-wd01-review.doc uploaded   Only had time to review through to Section 7. I’ll try to find more time next week for the remainder of the document.   kmip-cs-profile-v1.0-sd01-review.doc   Line 63 "KMIP Baseline Client" should be "KMIP Baseline Server".   Line 67 Which "Mandatory Test Cases" are being referred to? (The tests in Section 4?)   Line 81 Which "Mandatory Test Cases" are being referred to? (The tests in Section 4?)   Line 86 Are these the "Mandatory Test Cases" referred to in lines 67 and 81?   Line 87 This conflicts with lines 78, 79 and 80. Line 87 allows a client to support any one of the test cases; e.g. Create/Encrypt/Destroy, but lines 78-80 require that a client support BOTH Encrypt and Decrypt.   Starting at line 110, Test case 4.1.6, CS-BC-M-6-12 - Encrypt and Decrypt with Known Symmetric Key The block cipher mode is not specified. It should be specified either in the key Registration request, or in both of the Encrypt and Decrypt requests.   For better interoperability coverage, additional tests for at least the following are required:   - Additional block cipher modes. Testing only with the (insecure) ECB mode will not flush out potential implementation mistakes with the various feedback modes. - In conjunction with additional block cipher modes, some different padding methods should be specified. - In conjunction with additional block cipher modes, initialisation vector, counter, and nonce (where applicable) input by the client should be specified. - It is still unclear to me whether Block Cipher Mode and Padding Method attributes specified by the client in Encrypt and Decrypt requests can force the server to override these normally immutable attributes. Some tests illustrating expected behaviour are necessary. - Some error test cases would be useful; e.g. trying to perform an Encrypt operation using the wrong type of managed object; specifying incompatible or conflicting attributes like mode or padding; providing an IV and/or padding method for ECB mode; etc.   Line 117 "KMIP Baseline Client" should be "KMIP Baseline Server".   Line 120 Typo: missing "]"   Line 121 Which "Mandatory Test Cases" are being referred to? (The tests in Section 7?)   Line 134 Typo: missing "]"   Line 135 Which "Mandatory Test Cases" are being referred to? (The tests in Section 7?)   Line 140 Are these the "Mandatory Test Cases" referred to in lines 121 and 135?   Line 141 Does this mean that the vendor decides which test cases are mandatory for the client?   Line 142 This says that the server must support all of the test cases listed. Any suggestions on how to perform these tests, as they require different, incompatible server behaviour? Are you assuming some out of band communication (KMIP extension, non-KMIP, server management channel, human to human, etc.) to set up the server behaviour prior to running the tests in question?   Seed RNG with Server Accept, Seed RNG with Server partial Accept, Seed RNG with Server Ignore, and Seed RNG with Server Deny each return different responses (and presumably invoke different internal server behaviour - although the specification does not require this) for exactly the same request.   If Seed RNG with Server Accept is supported by the server, and performed multiple times, each followed by RNG Retrieve, must each returned random be identical? If not, is it allowed to be identical? If so, under what conditions is it allowed to be identical, or can it be forced to be identical?   John   From: kmip@lists.oasis-open.org [ mailto:kmip@lists.oasis-open.org ] On Behalf Of Tim Hudson Sent: Friday, 28 June 2013 12:25 AM To: kmip@lists.oasis-open.org Subject: [kmip] Groups - kmip-cs-profile-v1.0-wd01-review.doc uploaded   Submitter's message Updated conformance wording style. Updated test case style. Included test cases for 1.2. Applied new OASIS template. Note: the byte values for the test data in the "Advanced Cryptographic Tests" remains to be updated from the placeholder values. -- Tim Hudson Document Name : kmip-cs-profile-v1.0-wd01-review.doc Description Cryptographic Services Profile Download Latest Revision Public Download Link Submitter : Tim Hudson Group : OASIS Key Management Interoperability Protocol (KMIP) TC Folder : Drafts Date submitted : 2013-06-27 07:25:14  

On 8/07/2013 1:03 PM, John Leiseboer wrote: I recommend that the test cases in this profile document be non-normative. My reason for this is that the test cases do not exercise the conformance requirements sufficiently to verify that an implementation is conformant. None of the profiles with the test cases listed are meant to be an exhaustive regression test for a KMIP server (or client) as if that were the objective the profile documents would most likely all be thousands of pages to cover off on each element referenced by the conformance clauses. They will remain normative as they are necessary but not sufficient as previously discussed. The conformance clauses are written to cover off on the requirements and the test cases themselves are in addition to those base conformance statements and there are no statements within the documents which state that if you pass the test cases you are conformant - in fact the opposite statement is made - if you don't pass them you are non-conformant (that being one of the conformance statements). I think you have a fundamentally different view as to the purpose of the profiles and the test cases within them - a view which you haven't expressed until reviewing this particular profile despite the approach being discussed at the face to face and on numerous calls and used in the last round of interop which you participated in. It would be beneficial if you could separate out your meta discussion from the specific review feedback so it is clearer to others what the nature of the feedback is - which items are generic and which items are actually specific to the given profile. I assume you'll be reviewing all the other profile documents at the same level of detail and providing comments on those too? I do expect the test cases against profiles to expand over time based on experience with conformance testing - however we do have to have a starting point. I'll continue to expand on the test cases in the document as time permits but remember the object was to have the test cases documents out to support interop testing - so any additions may not be part of this interop round depending on the consensus view of the participants involved. I'll attempt to address more of the non-generic items you have raised separately. Thanks, Tim.