So, if I have a single security domain only system with a single client program, to encrypt/decrypt, would I use the CoProcessor namespace or would I just use the Encrypt/Decrypt ones?
Hema -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Davidson, John A. Sent: Wednesday, March 09, 2011 10:19 AM To: CICM Discussion List Subject: Re: [cicm] Channel and Conduit It does, thanks, Lev. Its clear (-er.) I see I need to reread the doc (when Im not so swamped). John -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Novikov, Lev Sent: Wednesday, March 09, 2011 8:53 AM To: CICM Discussion List Subject: Re: [cicm] Channel and Conduit John, On 2011-03-09 11:16, John Davidson wrote: > Could you give me a few words on why the channel cannot be separated > from the stream in a single domain. The concern I had was that the > control (is that the channel?) often needs to be isolated from the > stream in several dimensions (e.g. integrity + secrecy.) Just to clarify, when I say "controller" and "stream" I'm referring to the type of API objects that are returned to the client program; not what is happening inside the crypto. Also, I realize now that I need to qualify my statement more carefully. In CICM there are three namespaces that produce "single domain" channels: CICM::Emit (Random, Pseudorandom, etc.), CICM::Answer (Hash, Sign, Verify), and CICM::Coprocessor (Encrypt, Decrypt in a single domain). CICM::Emit contains Controllers and Conduits because you may want to emit data out of the module to another domain (using a Controller; you control the Channel, but don't see the data) but you may also want to retrieve the data into the current domain (using a Conduit; you control the Channel AND you see the data). CICM::Answer and CICM::Coprocesser only have Conduits because the client program that creates a Channel in a single domain also sees the results of that Channel (control the channel AND you see the data = Conduit). Technically, this is a design choice-- we could have said that multiple client programs are involved in a single domain operation (e.g., one to create the Channel and another to send the data and receive the result). However, coordinating this process for single domain Channels is harder when there isn't something like an external port as there is in a typical multi-domain high assurance scenario. Regarding your point about integrity and secrecy: CICM::Coprocessor channels come in several flavors including those that combine secrecy and integrity. Again, this discussion is about what happens in the client program, not what happens in the crypto. See <http://tools.ietf.org/html/draft-lanz-cicm-cm-00#section-18>. Let me know if this addresses your concern. If not, I can elaborate more on the origin of the Controller and Stream concepts and why you can't get at them separately in a single domain. Lev _______________________________________________ cicm mailing list [email protected] https://www.ietf.org/mailman/listinfo/cicm _______________________________________________ cicm mailing list [email protected] https://www.ietf.org/mailman/listinfo/cicm This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail. _______________________________________________ cicm mailing list [email protected] https://www.ietf.org/mailman/listinfo/cicm
