And while we're picking nits, should read "vendor NEUTRAL", not "vendor agnostic"...unless you believe that nothing can be known / proven wrt the existance of vendors. ;-)
-kevin -- Kevin W. Wall Sent from DroidX; please excuse typos. On May 17, 2011 11:06 AM, "Cottrell Jr., James R." <[email protected]> wrote: > Sound good. > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Bourget, Dennis > Sent: Monday, May 16, 2011 9:11 PM > To: CICM Discussion List > Subject: Re: [cicm] BoF Request for CICM at IETF 81 > > Again, I may be picking nits, but I still don't believe that the API > offers any security domain separation. > I would just delete "and thus offers". > > It would then read: > "The API is intended to support high assurance cryptography, security > domain separation, and > enhanced module, key, and channel management capabilities that are > vendor agnostic." > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Novikov, Lev > Sent: Monday, May 16, 2011 5:54 PM > To: CICM Discussion List > Subject: Re: [cicm] BoF Request for CICM at IETF 81 > > On 2011-05-13 at 13:34, John Davidson wrote: >> I am wondering if we need to (or even can) clarify what we mean by >> High Assurance. > > On 2011-05-13 at 17:56, John Fitton wrote: >> I would suggest defining High Assurance in terms of FIPS-140-2 >> Level 4. Of course FIPS 140-2 refers to the Common Criteria AL4 or >> higher, but does offer specific criteria to be used in the evaluation. >> That being said, however, while the stated goal is for a high >> assurance API, there is nothing in principal which limits the API to >> high assurance applications. > > On 2011-05-14 at 18:12, Dennis Bourget wrote: >> I just don't see how any API can provide "high assurance", it is the >> implementation of the API, host platform and operating system that >> would need to be evaluated to FIPS 140-2 or Common Criteria. For >> example, the API does not and cannot provide domain separation, I >> suggest that we strike that text from the charter. > > On 2011-05-16 at 13:08, Jim Cottrell wrote: >> I agree that the API by itself cannot provide "high assurance" but >> this API has been designed to be targeted for use in high assurance >> applications. > > Interesting discussion. > > What do people think of the following? It is based on Dennis's > suggestion, > but emphasizes that the API targets high assurance environments. > > The Common Interface to Cryptographic Modules (CICM) defines an > application > programming interface for the security services provided by > cryptographic > modules developed by multiple vendors. The API is intended to support > high > assurance cryptography, and thus offers security domain separation, > and > enhanced module, key, and channel management capabilities that are > vendor > agnostic. > > 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 > _______________________________________________ > cicm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cicm
_______________________________________________ cicm mailing list [email protected] https://www.ietf.org/mailman/listinfo/cicm
