kmip-interop-tech — archive

Testing extension

From: Tim Hudson <[email protected]>
To: [email protected]
Date: Fri, 15 Jan 2016 21:29:00 -0000

Thanks John for the detailed write up - that helps in understanding the issue from your perspective. On TC-312-12: The attribute indexes must be created in the order specified by the user as there are circumstances where the allocated attribute index value has specific meaning. Attributes pulled in from a Template are meant to be included first as the use of a reference to a Template is meant to basically be entirely a convenience mechanism for passing in common attributes. The specification states the logical order that things should be processed in (template names referenced in order followed by the individual attributes) although that could be worded more clearly (it is referring to the precedence when conflicting single instance attributes are provided). As the order of attribute index has special meaning it is absolutely essential that the attribute index assigned to the "first" value is indeed set to 0 so processing items in the reverse order is indeed non-conforming. This test case was also explicitly expanded to return the attributes from both the created object and the template so that it was clearer and to also cover the clarified handling of Templates in terms of their registration and that a Template has attributes which are not contributed to objects created using a reference to a template. Of course this specific issue becomes rather moot for most vendors once we finally remove the deprecated use of Templates. On TC-14*-12: Rejecting use of a key for wrapping where the key does not define a Key Role Type is a somewhat unfortunate (and also rather non-interoperable) approach to take. A server requiring that a clearly defined entirely optional item must be present is effectively mandating server specific behaviour which will preclude interoperation with vendors who follow the specification details that clearly note it is optional. Requiring that clients must include something marked optional is of course within the scope of the specification in the sense that you could (for example) configure your server to mandating that all clients must include a specific custom attribute in order for their keys to be accepted - i.e. this is technically able to be done - but pragmatically precludes multi-vendor interoperability. It is especially interesting in that the Key Role Type was defined to basically allow keeping the information that is contained within the scope of usage of TR-31. And Cryptographic Parameters are set by the client so you are basically enforcing something that the client did not specify should be enforced. That you did not reject the registration of the key that omitted a Key Role Type is inconsistent with your stated intent. I would expect a server to reject registrations that do not contain a Key Role Type if the decision has been made in such a server to treat Key Role Type as mandatory. In reality I think you've perhaps simply got a small logic issue there in that if the Key Role Type is not specified then there is meant to be no restriction on its usage in *any *context. If it is specified you arguably should enforce - but if it is not specified then the client has explicitly told you that it has no restriction on the Key Role Type. Note this also basically returns to the many previous discussions on Cryptographic Parameters - which unlike Cryptographic Usage Mask are explicitly intended to be able to be modified (and specified) by the client. Where you have a desire to include additional requirements on clients and/or servers for specific reasons (whatever those reasons happen to be) the approach is to document a profile that includes those requirements with a corresponding set of test cases to enable other vendors (if they see a demand for such a profile) to support an interoperable solution. Interoperability is the focus of the specification and adding vendor-specific interpretations of what is mandatory outside the context of a specific profile clashes with the interoperability goal of the specification. Profiles are a mechanism for allowing shared differing requirements/behaviour. Note your server explicitly notes not supported - [status=OPERATION_FAILED reason=FEATURE_NOT_SUPPORTED message=Key role must be KEK] - rather than a permission denied error. So from a Cryptsoft perspective we would mark both of those responses as failed. I'm happy to retest if you adjust the logic. Tim. On 15/01/2016 4:00 PM, John Leiseboer wrote: > > 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] > > [ mailto:[email protected] ] *On Behalf Of *Tony C > *Sent:* Thursday, 14 January 2016 8:30 PM > *To:* [email protected] > < mailto:[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 >