kmip — archive

[Rod Wideman]

It seems that the original intent of the Application Specific Identification attribute was to provide a way to describe how a managed cryptographic object is used, or to what it is associated (i.e., identify the application, not the object). I think this is still useful to have, in that objects can then be located that are associated with a particular application or usage. The current discussion seems to be oriented around using this attribute as a means to assign an identifier to the object itself (e.g., in the case of Scott's proposal, a Key ID, which I think is similar to what Stan is describing as a key name). This then makes me wonder what the Name attribute should be used for, and whether it would make sense to add one or more additional Name Type enumerations of various "key ID" or "key name" variants to address that specific need, and let the Application Specific attribute continue to provide a way to associate the object with applications. So for example, I might have a key that has a Name attribute and a Key ID name type. I use this key to encrypt files, so have Application Specific Id. attribute instances to describe the name space(s) of the files for which I use the key. But I may use more than one key to encrypt files in those name spaces, so if I have another key (having its own Name attribute and different Key ID name type), then I could set the same Application Specific Id. attribute instances with it. Now I can locate all objects (i.e., keys) associated with that particular application usage. So I see Name as referencing the object (i.e., pointing to it) and the Application Specific stuff pointing away from the object (i.e., where does it go). The need for "key id" seems to fit the Name attribute, but perhaps I'm missing something? Thanks, Rod Wideman Quantum Corporation (please disregard the confidentiality statement below)