kmip-interop-tech — archive

[Mathias Bjorkqvist]

All, Here are my summary notes from yesterday's interop call. Please let me know of any additions/corrections you might have. Best Regards, Mathias KMIP interop 2011-07-21 Several comments and recent discussion on the interop-list regarding attribute usage, and mainly when the index value '0' MAY/SHALL/SHALL NOT be specified. Consistency would be appreciated. Suggested solution is to require the server to set the attribute index value for '0' in responses. Affected sections in the specification are 2.1.1, 3, 4.12-4.16. Plans to streamline the handling in the next version of the spec (v1.1 CD-02), will return to this discussion once that version is out. Questions have also been raised regarding the Digest attribute, and namely what representation of the object the digest is calculated on. This applies in particular to Transparent Keys, but might also apply to other managed objects. A client may currently register an RSA private key in transparent form on a server, and the server may calculate the digest on e.g. the PKCS#1 byte string representation of the key or the TTLV-encoded Key Value structure of the key. From an interoperability perspective the result should be predictable. A Key Format Type field could be added to the Digest attribute, but you could also require that for a particular key format, the representation that the digest is calculated from SHALL be a specific format. Aspects to consider are also how the digest is to be used. If it is only for server-internal use (e.g. not allowing more than one copies of the same key in the system), then there might not be a need to specify this further in the protocol. If we want a key registered on two systems to have the same digest, something more is needed. And what if the same key is registered in two different format, should the digest still be the same? How real/common is a use case where a client performs a Locate using the Digest attribute value?