OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]