Hi Girish, On 2011-05-27 at 14:50, Girish Nanjundiah wrote: > 1. When the function encrypt() sends a packet to the Crypto, it emerges on > the black side encrypted and decrypt() is expected to decrypt this encrypted > packet. In order for the packet to be decrypted, there needs to be some > function that echoes the encrypted packet back through the black side. Since > this echoing back seems to be more of an application level function than a > driver function, what part of the code should be responsible for echoing the > encrypted packet back through the Crypto?
Another way of asking this question is: What functions move data from the remote (unprotected) side of a crypto into the local (protected) side? See also: "Does CICM only provide (specify) the "red" side API in a multilevel system?" http://www.ietf.org/mail-archive/web/cicm/current/msg00014.html http://www.ietf.org/mail-archive/web/cicm/current/msg00028.html You correctly point out that this is not a driver-level function. In fact, CICM does not define functions for simply moving data into the crypto. Therefore, you are free to use whatever transport mechanism works for you (e.g., POSIX socket). > 2. When create_en/decrypt_conduit is finished executing, it needs to store > an identifier (just a number really) to identify the conduit it has created > with the Crypto. Since both of these functions only return a status and a > CICM::En/Decrypt::Conduit pointer, the only way to store the identifier for > the conduit to use is to add it as a member variable to the Conduit class. > If the variable is to be private, we would also need a simple public member > function to access it. Is there a way to update the CICM API so that we can > store the conduit's identifier in one of the ways I listed? This is an interesting suggestion. We define KeyId for key identifiers, but we do not define a ChannelId for channel identifiers. This is because there isn't currently a way to lookup a channel by its identifier (like there is for keys, modules, and tokens). This is going to require some discussion. Normally, vendor-specific attributes are defined by extending the CICM base object and adding those properties. However, it seems like a common operation to store a vendor-specific identifier in a CICM object to make it easy to reference the underlying object later on. ** What do people think about extending the API to allow vendors to store a single numeric value to uniquely identify the objects to the underlying system? Lev _______________________________________________ cicm mailing list [email protected] https://www.ietf.org/mailman/listinfo/cicm
