Re: [kmip] KMIP Spec v1.2 wd05: Multiple Cryptographic Parameters for a Single Key

[Tim Hudson <tjh@cryptsoft.com>]

On 2/07/2013 11:51 AM, John Leiseboer wrote:
> Another interpretation that we could apply is that multiple instances of the Attribute Object are permitted, but that fields SHALL not be repeated in each instance.

There simply is nothing within the specification to support that
interpretation. Could you locate some text to support that anywhere in
the specification?
If you can locate such text (which I haven't seen) then the text would
clash with the examples (which I know are however non-normative) in the
usage guide and with common sense usage too (see the example in the
usage guide).

In addition, this whole area remains unchanged since the initial
contribution which went on to form KMIP 1.0. That doesn't mean it
shouldn't change, but absent a clearly demonstrated interoperability
issue we haven't made fundamental changes to KMIP other than addition of
functionality.

We do not have a single fixed policy for handling a particular view of a
security model in the manner that matches the model you are looking for
- this specification is about interoperability - it is not about
enforcing any particular security model across all vendors and users of
KMIP.

It is not that your concerns about the overall security have no merit
(in the general sense), it is simply that those are items addressed
outside of KMIP as this is how the group as a whole has approached each
of these areas. Each vendor has radically varying views on what the
right approach is from a security model perspective and each vendors
product takes a different approach to handling those items and has a
different way of interacting with the users.
There is nothing wrong with that.

No one has claimed that just using KMIP makes your solution secure -
that isn't the goal - the goal is interoperability. Security encompasses
so much more than that.

I suggest you take a look at each of the shipping products in the market
and apply each of the concerns you have raised against those products
including the ones you have worked on in former roles - and I think
you'll find that none of them actually address the range of items you
have raised - but they all offer value and are all seen as improving the
security in deployment.

Your concerns are in my view (at least) simply outside the scope of KMIP
(and most other cross-vendor key management standards).

However I do think you should draft a profile which contains the
additional behaviours and restrictions you think would address all the
concerns you have raised and propose it to the group. That is something
which can be done at any time and does not impact the schedule for KMIP 1.2.

Thanks,
Tim.