OASIS Key Management Interoperability Protocol (KMIP) TC

 View Only
  • 1.  Concerns with Encrypt, Decrypt, Sign and Verify

    Posted 11-14-2012 05:05
    After going through the specifics of the Encrypt, Decrypt, Sign and Verify proposal, I have a concern that we are trying to bite off more than KMIP should be attempting at this point. There are several reasons for this at this point in time as listed below: 1. The scope of KMIP specifically calls out key management related operations and to therefore to include generic crypto operations that focus on key use may be considered as out of scope for the current protocol. If we want to expand the functionality to include crypto API type functions this should be part of our re-scoping effort prior to inclusion in the specification.* 2. If we were to agree that the scope of KMIP does already include or should be expanded to include these types of generic crypto operations then we would need to ensure we do not confuse the market relative to today's existing crypto APIs (e.g. PKCS, JCE, OpenSSL & CAPI, etc...). Maybe I’m over-reacting and these additions are not intended to cover generic crypto operations but rather just operations necessary to protect keys while under management (encrypt, sign etc.). If so, we need to put specific bounds around these operations so that they relate explicitly to key management as called out in the current Charter. I think we need to always ensure that we don't confuse the market or allow KMIP to become another protocol that no one uses because it is seen as just something else that has to be supported but not fully in the market for its intended purpose of key management. * The KMIP Charter can be found at: https://www.oasis-open.org/committees/kmip/charter.php Bob L. Robert A. (Bob) Lockhart Chief Solution Architect - Key Management THALES e-Security, Inc.


  • 2.  Re: [kmip] Concerns with Encrypt, Decrypt, Sign and Verify

    Posted 11-14-2012 18:03
    Bob, Thanks for raising this. I had certain concerns with this too - Most of the initiatives that we have taken up for 1.2 seem to fall under "out of scope". We need to address these during re-chartering too. <snip> Out of scope areas include: Implementation specific internals of prototypes and products Multi-vendor Key Management facility mirrors or clusters Definition of an architectural design for a central enterprise key management or certificate management system other than any necessary models, interfaces and protocols strictly required to support interoperability between Actors in the multi-vendor certificate and key management framework. Framework interfaces not dedicated to secure key and certificate management ---> Certain areas of functionality related to key management are also outside the scope of this technical committee, in particular registration of clients, server-to-server communication and key migration. <----- Bindings other than tag-length-value wire protocol and XSD-based encodings. </snip> Thanks, Kiran


  • 3.  Re: [kmip] Concerns with Encrypt, Decrypt, Sign and Verify

    Posted 11-14-2012 18:20
    Bob, Kiran, and others ... On the in-scope or out-of-scope item discussion and the note that most of the focus for KMIP 1.2 is arguably outside the current charter we resolved in the face to face that we would head down the re-charter path removing all the out-of-scope items from the current charter for KMIP 1.2 but only commence that process after the OASIS organisation-wide vote on the KMIP 1.1 specification was complete and that we would work on each of the items in parallel with that process and the proposing companies would explicitly re-contribute them (or generally re-contribute all past contributions) prior to reaching a KMIP 1.2 specification draft. We have in the past worked on items noted as out-of-scope and proposals have been presented (on quite a few of the topics) and there has been no issues raised to date that working on those items is acceptable - provided that we do not place any out-of-scope item in a committee draft specification - i.e. only work products. See the brief note in the f2f day3 minutes on the topic. It is one of the challenges we face in the face to face meetings - how to have the details of the discussions more accessible to those who are not present physically at the meetings. Remote participation as many have noted is difficult. The minutes attempt to capture the key details - but the discussions are not always able to be noted with all the nuances. I'll respond on the scope of the cryptographic services proposal separately. Thanks, Tim.


  • 4.  Re: [kmip] Concerns with Encrypt, Decrypt, Sign and Verify

    Posted 11-14-2012 19:39
    On 14/11/2012 15:05, Lockhart, Robert wrote: > 2. If we were to agree that the scope of KMIP does already include or should be expanded to include these types of generic crypto operations then we would need to ensure we do not confuse the market relative to today's existing crypto APIs (e.g. PKCS, JCE, OpenSSL & CAPI, etc...). We have already agreed that the scope for KMIP 1.2 will include the cryptographic services (and a number of other items) and that we will alter the charter if required to enable that (which I've addressed in the earlier email today). We received commitment in principle to implementation of the cryptographic services from seven vendors - but of course that commitment does not include implementing everything in the scope - we fully expect each vendor to select the portion of the functionality which matches their anticipated market needs. As a vendor we (Cryptsoft) have committed to implementing the entire proposal and performing interoperability testing with other vendors following our usual strategy. Your reference to PKCS#11 (assuming that's the particular PKCS you were referring to) and JCE and OpenSSL and CryptoAPI are rather orthogonal to the current discussion - those are all cryptographic APIs and not wire protocol formats so there is simply little scope for confusion there in the market. If KMIP were to put an API within scope and document that then I too would share your concern about potential confusion - but there are ways to address that. As it stands KMIP does not mandate or attempt to offer an API for developers - rendering I think your expressed concern as moot. We do also have a range of SDKs which offer those APIs to developers - as it makes sense to enable existing application integrations to take advantage of key management functionality offered by vendors who support KMIP - but that is something outside the scope of KMIP itself. Other vendors also offer additional APIs - each vendor taking the approach they feel best meets the needs of their customer base. Once cryptographic services are implemented then a broader range of capability is possible for those sorts of API integrations. The proposal is broader than what we had originally started out with - but that has been based on direct feedback from other TC members - it seems everyone wants just that little bit extra to support some use case of relevance to them. That leads to the following two questions a) are you still committed in principle to implementing the cryptographic services (or a subset thereof) b) do you have any specific feedback on the proposal itself beyond the scope of the operations contained in it Thanks, Tim.


  • 5.  RE: [kmip] Concerns with Encrypt, Decrypt, Sign and Verify

    Posted 11-14-2012 22:37
    > On 14/11/2012 15:05, Lockhart, Robert wrote: > > 2. If we were to agree that the scope of KMIP does already include or > should be expanded to include these types of generic crypto operations > then we would need to ensure we do not confuse the market relative to > today's existing crypto APIs (e.g. PKCS, JCE, OpenSSL & CAPI, etc...). > Tim responded: > We have already agreed that the scope for KMIP 1.2 will include the > cryptographic services (and a number of other items) and that we will > alter the charter if required to enable that (which I've addressed in > the earlier email today). I think it would be more accurate to say that there was agreement to proceed with development of a proposal to include cryptographic services (and a number of items) in KMIP 1.2. There's a lot of work required to go from agreement to work on the proposal, to agreeing to include the output of the proposal (use cases, spec changes, usage guide material, test cases, etc.) in 1.2. I note that we also agreed at the face to face to develop use cases for cryptographic services. I believe that the streaming use cases I developed address some of the uses for "get random". Bob submitted a draft use case document for crypto services in the cloud, and use of "get random" for "attested get". As we agreed in the February face to face, we should first develop the use cases, then work on the detail. The only mature use case related to crypto services at the moment is my own streaming key delivery, and the current proposal fails to satisfy that use case. With due respect to Bob, his two use cases are not nearly developed enough to allow us to proceed with a detailed cryptographic services proposal. (More on this below.) I made an attempt to list some of the use cases and usages of "get random" in my comparison document of a few weeks back. I'll be the first to admit that it is not a suitable replacement for a use case document. But even so, in the absence of anything else, it's the best we have. > The proposal is broader than what we had originally started out with - > but that has been based on direct feedback from other TC members - it > seems everyone wants just that little bit extra to support some use case > of relevance to them. I propose that we have a bit of a breather, and reconsider what we're trying to do with crypto services. In particular, I'd like to break it up into at least two different proposals: 1) "get random", and 2) "crypto services" (such as encrypt, decrypt, sign, verify, etc.). For each of these I propose that we develop proper use cases. During use case review, we can decide what is in scope or out of scope. As Tim says, the Cryptsoft crypto proposal has changed significantly from the one presented at the face to face. I would say that this is a direct consequence of not having an agreed set of use cases. Those of us who are engineers on the TC will understand very well that is not possible to design to a moving target. I don't know about others on the TC, but I certainly haven't seen much open discussion on individual's use cases. Let's have the use cases formally written down so that we are all working from the same source of requirements. I fully understand the urgency of some TC members in locking down a crypto services proposal. But we do need to do this properly. I have been involved in the development of many products and a few standards over the last 35 years - most of them involving network protocols and many involving security: from "trivial" single user systems, through to very complex military systems. In my experience, the most difficult designs to get right are those involving networks, shared services, and security. KMIP crypto services checks all these boxes. Think about Bob's cloud crypto use case (even incomplete as it is). A server, operated by a third party, providing cryptographic services over a network to potentially many clients. Potentially the client mix includes malicious and/or erroneous implementations. Almost certainly, isolation between clients will be a requirement, as will logging, auditing, active management of operations, control of key material usage, identification of and response to compromise of key material, systems, and/or communications. Is the current crypto services proposal intended to address this usage? If so, is it good enough? Is this something that we want to include in KMIP? > That leads to the following two questions > a) are you still committed in principle to implementing the > cryptographic services (or a subset thereof) > b) do you have any specific feedback on the proposal itself beyond the > scope of the operations contained in it > Regards, John


  • 6.  Re: [kmip] Concerns with Encrypt, Decrypt, Sign and Verify

    Posted 11-15-2012 01:10
    On 15/11/2012 08:36, John Leiseboer wrote: As Tim says, the Cryptsoft crypto proposal has changed significantly from the one presented at the face to face. The proposal has changed because of feedback from multiple technical committee members wanting additional functionality and it has been reviewed by those folks who have been participating in its development which is exactly how proposals are meant to work within the TC. That cooperative feedback and iterative cycle then bringing back to the wider group is essential how KMIP has been developed. We don't believe in developing proposals in isolation or your end up with the situation of a vendor having done a substantial body of work to propose something which is of no interest to the rest of the group. If you want to add capability to KMIP which is not well understood then we have agreed as a group that use cases make sense to define to reach a common understanding where variations exist. We also discussed in the face to face that for something like adding cryptographic operations into KMIP the concepts were well understood and that describing a set of use cases of the form a-client-wants-to-{encrypt,decrypt,sign,verify,mac,etc} was an unnecessary exercise. For the QKD-specific context that certainly was needed as your descriptions simply didn't make sense to the wider group and Bob also offered to show the context of usage within a cloud environment but that was more from the perspective of showing where the two areas can overlap and certainly not as a prerequisite for bringing this proposal forward and to also work with Kelly on the device attestation mapping. That was discussed. The path forward was agreed. At this stage it is pretty clear to me that you are fundamentally opposed to the proposal and I assume that it means that QLabs will not be implementing it going forward assuming the majority of the TC votes to accept and that the list of supporting vendors drops to six from seven and as always that's your choice to make. However raising security issues which have nothing to do with this particular proposal and are sufficient generic and nebulous to apply to all of KMIP is simply a delaying tactic. Nothing in the document you wrote is specific to the cryptographic services proposal. If the group as a whole feels the scope of the proposal is too wide then we will take that feedback on board - however to date the opposite of that has been the direct feedback - with additional capability being requested by multiple vendors. Keep in mind that a substantial portion of existing vendor products have cryptographic capability built in - it is simply either only in the vendor proprietary protocols or implemented as vendor specific KMIP extensions. What we have proposed is to actually have a standard way of representing capability for which there is clear demand (vendors don't generally add capability for which there is no market demand). If you have substantial support from other vendors within the KMIP TC for the views you have expressed then I'd like to hear from them as well. The entire group is well aware of your views on the topic and repeating the previous discussions simply is not a productive use of time in my view. Tim.