OASIS Key Management Interoperability Protocol (KMIP) TC

The spec (1.2 wd07) lists NIST SP800-57 Part 1 as a normative reference. What is the difference between a normative reference and a non-normative reference with respect to KMIP, and KMIP profiles? What is the purpose of normative references? For example, for a server that conforms with the asymmetric key lifecycle profile (v1.0 wd02), it is now MANDATORY that the server be non-compliant with NIST SP800-57 Part 1. Is this intended? Similarly, is it intended that a server that complies with SP 800-57 Part 1 be non-conformant with KMIP, or the KMIP asymmetric key lifecycle profile? I find it a little strange that it could be necessary to create NIST SP800-57 Part 1 profile variants of profiles like the AKLC profile when NIST SP800-57 Part 1 is already a normative reference. 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 ----------------------------------------------------------------------

On 9/08/2013 4:20 AM, John Leiseboer wrote: it is now MANDATORY that the server be non-compliant with NIST SP800-57 Part 1. If this is the same issue you raised at the last face to face then it was discussed at length at the time; if this is a new issue then you need to elaborate as you are leaving it up to the reader to guess what the issue is. Pointing at the specific behaviour in the profile test case and the relevant items within SP800-57 part 1 and KMIP would help. If you are just referring to the text in 7.3 (c) then you need to look back at the rest of SP800-57 part 1 and the previous discussions on that topic and note (as discussed in the face to face) that it depends on which type of asymmetric key pair is being referred to and also has to be looked at in the light of the other context statements within SP800-57 part 1 on asymmetric keys and then also the context within KMIP as to where and how such a conditional requirement should be handled. The discussion at the time (in the face to face and prior and subsequently) was on whether or not it is a requirement for a KMIP server to automatically revoke a public key managed object when a private key managed object is revoked. The consensus of the group was that mandating that the server always revoke was not a requirement within KMIP and was not a requirement within SP800-57 (it was a lively discussion) in terms that it depended on how you read the various items and which specific type of asymmetric key pair was in use. It was also discussed that a client can elect to perform this operation (and could even do this in a batched request) so nothing precluded meeting that behaviour if it was indeed a behaviour that someone felt was necessary to meet in their particular circumstances. As the client is responsible for performing the revoke operation it can also be equally responsible for performing any other operations required as a result of the compromise. The discussion also covered the flip side - that if Revoke needed to always impact other managed objects then we would need to make a specification change and outline the circumstances under which this should occur. There was also no consensus to tackle that as a work item for KMIP 1.2. This behaviour has been in the asymmetric key life-cycle document since they were circulated back in January prior to the previous round of testing. You've provided feedback before - but this is the first time I've heard you claim that the profile requires non-compliance with SP800-57 - so I'm trying to understand how you reach that (incorrect) conclusion in light of the previous discussions. Thanks, Tim.

> The discussion at the time (in the face to face and prior and subsequently) was > on whether or not it is a requirement for a KMIP server to automatically revoke > a public key managed object when a private key managed object is revoked. To clarify: The problem is not that a KMIP server is required to revoke. The problem is that AKLC-M-3 requires that the KMIP server NOT revoke. A server that does revoke the public key will not return "Preactive" when the state is checked at time 7. This is not listed as an acceptable deviation. The consensus of the group was that for a KMIP server to automatically revoke was not required. The behaviour described by the test case is that for a KMIP server to automatically revoke is forbidden. -- Michael

On 9/08/2013 6:46 AM, Michael Stevens wrote: >> The discussion at the time (in the face to face and prior and subsequently) was >> on whether or not it is a requirement for a KMIP server to automatically revoke >> a public key managed object when a private key managed object is revoked. > To clarify: The problem is not that a KMIP server is required to revoke. The problem is that AKLC-M-3 requires that the KMIP server NOT revoke. A server that does revoke the public key will not return "Preactive" when the state is checked at time 7. This is not listed as an acceptable deviation. > > The consensus of the group was that for a KMIP server to automatically revoke was not required. The behaviour described by the test case is that for a KMIP server to automatically revoke is forbidden. Thanks for confirming this email thread is about that particular issue and not some other (unstated) one - it was entirely unclear what the context was from John's initial email. We also discussed (repeatedly) that any dependence on behaviour which was not mandated by KMIP being performed by a KMIP server would be inherently non-interoperable and that if this was a behaviour that a vendor felt was appropriate that a separate profile should be constructed to cover that range of behaviours (and the other associated items) as profiles (and not the specification itself) is how these things are meant to be handled. Vendors are always free to elect which profiles their products support. So far we have not seen any profile proposal from Quintessence on any of the additional behaviours that you have added into your server - and each of those behaviours in my view has merit in a range of contexts - however as default behaviours they break interoperability. Many vendors do extend behaviours as optional items - and allow configuration on a per user (or other) basis. We have previously offered to co-author one or more profiles covering the behaviours we see merit in - and that offer remains open. Tim.

> Thanks for confirming this email thread is about that particular issue and not > some other (unstated) one - it was entirely unclear what the context was from > John's initial email. > Another issue is that SP800-57 states: > A private signature key shall not be retained in the deactivated state, but transition > immediately to the destroyed state. While the test case requires the server to hold on to a private signature key in the deactivated state in the interval between the revoke and the destroy request. A minimal change to avoid any interop issues here is to change the cryptographic usage mask from Sign to some other usage, such as key transport. To clarify our position, the objection is not that the key lifecycle profile outlines non-interoperable behaviour like failing to revoke a public key on compromise of the private key. The objection is that this non-interoperable behaviour is listed as mandatory. -- Michael

On 9/08/2013 7:31 AM, Michael Stevens wrote: > The objection is that this non-interoperable behaviour is listed as > mandatory. Or more precisely worded, the asymmetric key life-cycle profile is non-interoperable with a server which performs additional actions not mandated or specified within the KMIP Specification (which is itself non-interoperable) - such actions were discussed at length in the last face to face. And for the additional context for those who haven't participated in the public interoperability testing and demonstrations in January and more recently in July this particular test case within the profile is one where the server from one vendor does not pass and the servers from all the other vendors that support the underlying capability do. Again, we have previously offered to co-author one or more profiles covering the behaviours we see merit in - and that offer remains open - and additionally we could commit to attempt to include that in the next round of interop testing (Dec/Jan) should you be willing to proceed with a profile - although I think that will miss the timing for inclusion with in the batch of KMIP 1.2 documents. Nothing precludes us from advancing a profile separately. Tim.