[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [kmip] Groups - KMIP 1.3 Custom Security Attribute Proposal uploaded
Mark, David,
The KMIP specification proposal is meant to help start the conversation for what needs to be updated in the specification. Once that is agreed to we plan
to also develop a profile document that will focus on how the client and server should work with the additional security attributes. The profile document is aimed at supporting NIST requirements for Cryptographic Key Management Systems (800-130 and 152). In this we are aiming for the security
attributes to play a supporting role for a subset of the requirements in 800-130/152. The KMIP specification only handles how a client and server communicate. The 800-130/152 docs also require a whole mess of other requirements that are not applicable to
the KMIP specification and would be up to the various server and client vendors to implement if they intend to support the 800-130/152 documents. We are recommending the addition of security attributes so that the KMIP specification can support as a communications
protocol the client/server interactions that are part of the 800-130/152 documents. This goes back to our face to face presentation back prior to the RSA conference, as well as discussions that were had at the NIST Cryptographic Key Management Workshop which
reviewed the 800-152 Federal Cryptographic Key Management profile draft. Would it help to also have the recommended updates for test cases and the Profile document to complete the whole picture on how the security attributes are
intended to be handled? Regards, Joe Brand From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org]
On Behalf Of Mark Joseph Hi Chuck, First let me state that I am a big supporter of what you are trying to do. The problem I have is what appears to me a short term "hack" (for lack of a better word) instead of the proper standards based approach to solve the real problem.
I think the wording is easy. Just replace "key material" with "managed object".
So why the rush? Why do a short term thing when the right way to do it is to add a real attribute? We can still add a real attribute to KMIP 1.3 which is FAR from being finalized. If you need a short term thing for a customer or project then add an "X-" attribute for your application cause I still don't see a difference between "X-" and "ZX-". There are no additional server guarantees that the "ZX-" data itself
is secure.
Yup I understand that and that is why I suggested a structure with a type field. Sending an opaque binary blob of data is hardly a way for a "standard" to encode semantics. Especially of a concept such as this.
Why can't we add an new attribute to KMIP 1.3? I don't see that we are even near to a final deadline for new features. I promise to add it into our P6R client for KMIP 1.3 so lets take the time and do it right instead of eventually
getting it done 2 different ways (a ZX- attribute and a real attribute).
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]