Re: [kmip] NIST SP800-57 Part 1 - Normative Reference

[Tim Hudson <tjh@cryptsoft.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.