kmip-interop-tech — archive

[John Leiseboer]

[I have leave of absence from the KMIP TC until late September. I will not be participating in calls during this period. I will have intermittent email access during this time. I apologise for the length of this email, but due to my absence from TC meetings, email will be my only means of communicating on this - and other - topics.] There have been email discussions, a proposal, and discussion at the last meeting on clarification of Cryptographic Parameters. In summary: - Several new Cryptographic Parameters have been proposed for GMAC, CTR and CMAC modes of operation. I believe that there is general agreement that these should be added to the specification. There is possibly still some work required to finalise the text in the specification and usage guide, but I believe we have consensus on this topic. - I submitted a proposal for tightening the handling of Cryptographic Parameters with the new cryptographic operations. In essence, when Cryptographic Parameters have already been associated with a key, and if a cryptographic operation is requested by a client with conflicting cryptographic parameters, the operation should fail. I have received off-list support for this proposal, and Tim has voiced objections on the list to this proposal. Current status is unresolved. - I raised a need to clarify the intent behind Cryptographic Parameters on the last call. Prior to the introduction of the new cryptographic operations, I thought the intent was quite clear: [1.1 spec. Same text appears in draft 1.2 spec] "The Cryptographic Parameters attribute is a structure (see Table 47) that contains a set of OPTIONAL fields that describe certain cryptographic parameters to be used when performing cryptographic operations using the object." Ignoring the new server-based cryptographic operations (so considering just the 1.0 and 1.1 specifications), cryptographic operations are performed by a client. The text above, in my opinion, clearly indicates that the client should use the Cryptographic Parameters associated with the managed object when performing cryptographic operations. Continuing to ignore the new cryptographic operations, there are just two areas of possible uncertainty: 1. What if no Cryptographic Parameters have been defined? I think it is reasonable in this case for the client(s) to use whatever Cryptographic Parameters are consistent with the object type and operations to be performed. This then becomes a client-controlled and managed decision, outside the scope of KMIP. 2. What if multiple, conflicting Cryptographic Parameters have been defined? I discussed this in emails a couple of weeks ago. We briefly discussed this at the last meeting. I don't believe that we agreed on the intent of the standard. In my opinion, when multiple Cryptographic Parameters are defined, the intent is to treat them as a "white list". In other words, the client should restrict itself to using one (or more) of the sets of Cryptographic Parameters when performing cryptographic operations. The remaining issue then becomes whether only one of the choices of Cryptographic Parameters should be used, or if all of them can be used at different times. Enforcement of the behaviour is outside the scope of KMIP - it is under the control of the client(s). Should we provide guidance one way, or the other, or both ways in the usage guide? When we introduce cryptographic operations into the standard, we should - I believe - be consistent in handling of Cryptographic Operations between server and client. In other words, if the client should use the cryptographic parameters (when present) for cryptographic operations, so should the server. The difficulty that arises is that Cryptographic Parameters are optional, so when there are none associated with a Managed Object, they need to be supplied by the client when requesting a server-based cryptographic operation. When multiple instances are associated with a Managed Object, again the specific CPs to be used must be supplied by the client. This latter case, introduces the possibility of a client specifying CPs that are not associated with the Managed Object - a conflict can arise. Similarly the case where only a single CP is associated with a Managed Object can lead to conflict when a client requests different CPs be used for a server-based cryptographic operation. These are the issues that I address in my proposal for tightening the handling of Cryptographic Parameters with cryptographic operations. I believe that actions were given to Judy, Kiran and myself to see what the specification and usage guide say about Cryptographic Parameters, and if additional specification or guidance is found to be necessary. I think both are necessary. I hope my opinions are clear on clarifications that are needed. We need a decision to be made whether clarification is needed, and if so, what the clarification should be. I believe that this is still an open issue at this time. Until these Cryptographic Parameters issues are resolved, I do not believe that the specification, the usage guide and the cryptographic services profile documents should be advanced to committee draft status. Regards, 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 ----------------------------------------------------------------------