Question for today's agenda: ID Placeholder

Hi Tony

 

Would you please add the following question regarding ID Placeholder to today’s agenda.

 

Cheers,

… Dave

 

Initial conditions:

 

Managed Cryptographic Object (Name)

State

foo

Deactivated

bar

Active

 

Batch request:

·         Batch Order Option = true

 

Batch Item #

Operation

ID Placeholder

(after Operation)

Comment

1

Locate [Name=foo]

ID Placeholder=UID(foo)

Locate by Name sets the ID Placeholder to foo

2

Revoke [UniqueIdentifier=UID(bar)]

ID Placeholder=No change=UID(foo)

This Revoke explicitly sets the UniqueIdentifier. Revoke does not [cannot] set the ID Placeholder.

3

Destroy [UniqueIdentifier=ID Placeholder]

ID Placeholder=No change=UID(foo)

Destroys foo!? This Destroy does not explicitly set the UniqueIdentifier, so implicitly uses the ID Placeholder, which identifies foo.

 

It seems strange, and hazardous, that the Locate operation’s setting of the ID Placeholder can leapfrog the Revoke operation’s explicit setting of the UniqueIdentifier to have effect on the operation following Revoke. A reasonable expectation for the above scenario would be that the Revoke operation sets the ID Placeholder to its explicitly set UniqueIdentifier (thereby resulting in the Destroy of bar instead of foo).

 

QUESTION:

Why does the KMIP specification deny setting of the ID Placeholder to operations like Revoke, Check, Get, and others that operate on a single, possibly explicit UniqueIdentifier?

 

BTW – As pointed out by Judy Furlong, the KMIP specification seems to have neglected ID Placeholder w.r.t. some of the newer operations [e.g. Split Key].

 

Cheers,

… Dave

 

The information contained in this electronic mail transmission 
may be privileged and confidential, and therefore, protected 
from disclosure. If you have received this communication in 
error, please notify us immediately by replying to this 
message and deleting it from your computer without copying 
or disclosing it.