It seems to me that high assurance may well be needed in cases with only one domain. Is that out of scope?
Richard Graveman On Sat, May 21, 2011 at 10:30 PM, Novikov, Lev <[email protected]> wrote: > John, > > On 2011-05-19 at 10:49, John Davidson wrote: >> I would vote for it as it is now, but I might even be pinch more >> satisfied if it said some of this kind of stuff: >> >> The Common Interface to Cryptographic Modules (CICM) defines an >> application programming interface for the security services provided by >> cryptographic modules developed by multiple vendors. It provides >> enhanced module, key and channel capabilities that are intended to be >> vendor neutral. The API is structured to enable it to operate in IA >> environments that enforce domain separation. This enables it to be >> adaptable to high assurance IA applications. > > It seems that you are trying to distinguish between environments that > enforce domain separation and high assurance environments. I've been thinking > about how to incorporate that point into our existing text. > > What do people think about the following? > > The Common Interface to Cryptographic Modules (CICM) defines a > vendor-neutral application programming interface for security services > provided by cryptographic modules developed by multiple vendors. The API > defines enhanced module, key, and channel capabilities and is structured to > to enable applications to operate in environments that enforce security > domain separation, such as high assurance environments. > > While I can see the point being made, it might make it harder for people who > are not familiar with our fine distinctions (i.e. the rest of the IETF) to > understand why CICM is important. > > I'm open to other suggestions. > > Thanks, > 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
