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: Use cases for mutating attributes

I collected the examples given for why the server may have legitimate cause to mutate an attribute.  If someone has another use case, please send it out to the list.

For each example, I tried to list which Attributes could be mutated.

From Robert Haas:

* Collisions with already assigned names

Affected Attributes: Name, Application Specific ID

* Backdating of the lifecycle dates

Affected Attributes: Activation Date, Process Start Date, Protect Stop Date, Deactivation Date

* Use of algorithm parameters considered insecure. 

Affected Attributes: Cryptographic Length, Cryptographic Parameters (Cipher mode, Padding, Hash Algorithm, Role Type), Cryptographic Usage Mask

From Marcus Streets:

* Client requests a key and asks to be allowed to encrypt 1000 blocks but
the server knows that it has only 500 blocks left.

Get Usage Allocation explicitly allows the server to return an allocation smaller than requested.

* When registering a key, if the client requests a lifetime that is
plainly wrong, for example suggesting a Triple DES key be used to
encrypt a Peta byte - the server needs to be able to correct this to a
sensible value.

Affected Attributes: Usage Limits

I think sanitizing lifecycle dates and usage limits are an acceptable use of mutations that clients can adapt to without significant effort.  

Changing names and cryptographic parameters, however, could make things very challenging for clients.  How can the server intelligently modify a client requested name and be sure it still serves the client's purpose?  How does the server know that the client can perform a cryptographic function with a longer key, or a different cipher mode?  I think interoperability may be better served by not allowing such mutations.


-AlanThe 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]