kmip-interop-tech — archive

Testing extension

From: John Leiseboer <[email protected]>
To: [email protected]
Date: Fri, 15 Jan 2016 06:00:00 -0000

Sorry for the spam, but it seems that jet lag and late nights have scrambled my senses. Please forget my comments on TC-14*-12 below. This is what I should have said: TC-14*-12 . These test cases exercise wrapping operations. Again, one client vendor has questioned the result from the Qlabs’ server, and one client vendor has given us a pass result. The Qlabs’ server strictly enforces Key Role Type. In this test case, Key Role Type is not specified, and therefore the Qlabs’ server returns an error if a wrap operation is requested using a wrapping key which does not have the Key Role Type attribute set to “KEK’. The specification says this attribute is optional and is silent on what the server could or should do with this attribute. Table 56 defines the KEK key type as “Key Encryption or Wrapping Key”. QuintessenceLabs’ decided to disallow wrapping operations on the server if the key role type is not set to KEK; i.e. if the key role is not defined to be key encryption or wrapping key. I am quite happy for QuintessenceLabs to remove its claim for conformance with this set of test cases if that’s the majority opinion of the group, but I don’t want to do this without first getting that opinion. So, does the group believe that this test case should permit servers to return an error if the Key Role Type is not set to KEK? And can this test case allow the client to set the Key Role Type to KEK in order to allow servers with strict enforcement policies to pass? Regards, John From: [email protected] [mailto:[email protected]] On Behalf Of John Leiseboer Sent: Thursday, 14 January 2016 9:12 PM To: Tony C <[email protected]>; [email protected] Subject: RE: [kmip-interop-tech] Testing extension On behalf of QuintessenceLabs, I am happy to see the test period extended. I would also like to raise a couple of items for discussion in the group please. TC-312-12 . One client vendor has questioned the result obtained from the Qlabs’ server. At least one other client vendor has given us a pass result. This test case sets a multi-valued attribute with two different values – one value coming from a Template, the other value coming directly from the request. The test case response message shows that the template-defined value has index 0, and the request defined attribute value has index 1. The QuintessenceLabs server assigns the indexes the other way around. I don’t believe that the standard specifies the index order, therefore I believe that either order is conformant. Does anyone have a different opinion, and does anyone object to allowing either order of index to be a valid response for this test case? TC-14*-12 . These test cases exercise wrapping operations. Again, one client vendor has questioned the result from the Qlabs’ server, and one client vendor has given us a pass result. The Qlabs’ server strictly enforces cryptographic usage. In this test case, a cryptographic usage mask is not specified, and therefore the Qlabs’ server returns an error if a wrap operation is requested using a wrapping key which does not have the ‘Wrap Key’ Cryptographic Usage Mask set. The specification is arguably silent on how the server should behave, but the specification is clear on how a client should behave: 3.19 Cryptographic Usage Mask The Cryptographic Usage Mask attribute defines the cryptographic usage of a key. This is a bit mask that indicates to the client which cryptographic functions MAY be performed using the key, and which ones SHALL NOT be performed. I believe that the above is meant to be interpreted as which cryptographic operations the client may PERFORM using the key and which cryptographic operations it SHALL NOT perform using the key. Arguably though, it could be interpreted to mean that the client should not expect the server to perform a cryptographic operation if the mask is not set appropriately. In any case, QuintessenceLabs’ decision to disallow cryptographic operations on the server if the mask is not set was not a result of interpreting, or misinterpreting what the standard says. We made the decision to also apply this requirement to cryptographic operations that are performed on the server to be consistent with required client behaviour, and because we believe that our server should strictly enforce this attribute for security reasons. I am quite happy for QuintessenceLabs to remove its claim for conformance with this set of test cases if that’s the majority opinion of the group, but I don’t want to do this without first getting that opinion. At the heart of this test case (and the standard), is whether operations forbidden on the client by the standard should be permitted on the server. Given all other things being equal, should a key not marked for Wrap operations be permitted to be used for wrapping on the server, while at the same time being forbidden for wrap operations on a client? Regards, John From: [email protected] [ mailto:[email protected] ] On Behalf Of Tony C Sent: Thursday, 14 January 2016 8:30 PM To: [email protected] Subject: [kmip-interop-tech] Testing extension Hi folks, I've had multiple requests to extend testing into next week. Would anyone who has an issue with extending the test period until next Wed 20th at 12pm Pacific Time please let me know ASAP? Thanks, Tony