OASIS Key Management Interoperability Protocol (KMIP) TC

kmip-testcases-v1.2-wd01-review 2.2.28 TC-141-11 - Key Wrapping using AES Key Wrap and No Encoding 2.2.29 TC-142-11 - Key Wrapping using AES Key Wrap with Attributes Both of these test cases register a wrapping key and a key to be wrapped. The Get operation is used to retrieve the wrapped key. However, the wrapping keys are in the Pre-Active state, and therefore the wrap operation should be denied (if the State attribute is honoured by the server), and the Get operation should fail. These test cases have been around for a while, and included in past interop tests. Those of us who passed the tests previously should be wrapped hard on the knuckles for not picking this up earlier. John ---------------------------------------------------------------------- John Leiseboer QuintessenceLabs Pty Ltd Chief technology Officer Suite 23, Physics Building #38 Phone: +61 7 5494 9291 (Qld) Science Road Phone: +61 2 6125 9498 (ACT) Australian National University Mobile: +61 409 487 510 Acton ACT 0200 Fax: +61 2 6125 7180 AUSTRALIA Email: JL@quintessencelabs.com www.quintessencelabs.com ----------------------------------------------------------------------

I suggest a simple change to 3.17 (lines 861-862 in wd06) to align the description with SP800-57-1 would make sense to include in the following form. A change from the current wording of "Pre-Active: The object exists but is not yet usable for any cryptographic purpose." to new wording of "Pre-Active: The object exists but SHALL NOT be used for any cryptographic purpose." This should not be a technical change in the specification but simply an update to make it clearer. Further reviewing of state and reflecting back on the discussion Saikat recently raised, I think it would also make sense to add additional text into 4.10 in the Get operation to add the following: "A server SHALL NOT return a Managed Cryptographic Object that has a State of Destroyed or Destroyed Compromised." If the server is enforcing the State rules in all contexts then this is also another area where it needs to be clear that this is required. In the two other KMIP 1.1 operations where the server is using a key for cryptographic purposed (Get where wrapping may be occuring, and DeriveKey) there should also be an addition note that the Managed Cryptographic Object being referred to must have State of Active. That should also be included in each of the new KMIP 1.2 cryptographic operations if we are going to take the path of repeating that note in each operation. I'm unclear as to whether or not that should also be applied to Create/Join SplitKey operations - in that those are effectively mechanisms for import/export using multi-party methods. Tim.