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.
Perhaps the following: The Common Interface to Cryptographic Modules (CICM) API defines a "standardized" application interface for the security services provided by cryptographic modules developed by multiple vendors. The API supports security domain separation, and enhanced module, key, and channel management capabilities that is vendor agnostic. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Fitton, John Sent: Friday, May 13, 2011 2:56 PM To: CICM Discussion List Subject: Re: [cicm] BoF Request for CICM at IETF 81 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. I would also point out that the Orange Book (as was the entire original Rainbow series) was targeted at information processing systems. These systems were essentially large data bases with many users gaining access via dedicated terminals, and there are those who would argue that the old assurance levels, were also not that well defined. As these system evolved and internet access was introdouced there was additional volumes created to address some of the security issues involved. I would argue that nothing in the Rainbow series specifically addressed security requirements or assurance levels for cryptographic modules. One advantage of the Common Criteria, is that the meaning of any given Assurance Level for a given application (e.g. a Cryptographic module) can be defined through an evaluation profile. Another advantage is that it is an internationally recognized set of criteria with a group of international evaluation/certification bodies. ________________________________________ From: Davidson, John A. [[email protected]] Sent: Friday, May 13, 2011 1:34 PM To: CICM Discussion List Subject: Re: [cicm] BoF Request for CICM at IETF 81 Lev, I am wondering if we need to (or even can) clarify what we mean by High Assurance. Assurance levels were fairly well-defined under the Orange Book but that has been grayed out by the move to international flavored Common Criteria. Today when we say we are addressing HA, it is no longer clear to me whether we mean to restrict our view to approaches that are logically "closed form," or if we mean just a better version of "best effort," whatever that is. In my mind, there are IA critical capabilities we can support with one that may be ruled out by the other. Thanks, John -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Novikov, Lev Sent: Friday, May 13, 2011 10:01 AM To: [email protected] Cc: CICM Discussion List ([email protected]) Subject: [cicm] BoF Request for CICM at IETF 81 I'm formally requesting a BoF at IETF 81 to form a CICM WG based on the draft charter below. Updated version at: http://code.google.com/p/ietf-cicm/wiki/WGCharter Discussion also at: [email protected] Thanks, Lev Draft CICM Working Group Charter = Description of Working Group = The Common Interface to Cryptographic Modules (CICM) API provides high assurance crypto applications with a security framework that accommodates the needs of a high assurance environment including security domain separation, and enhanced module, key, and channel management capabilities. The purpose of the CICM Working Group is to shepherd the CICM specification documents to publication and provide guidance for any new submissions related to high assurance cryptos. Specifically, the Working Group will: * Complete existing requests: * replace algorithm strings with OIDs * use ABNF notation for unique identifiers syntax * add module events for symmetric and asymmetric key filled * Shepard the following documents to publication: * draft-lanz-cicm * draft-lanz-cicm-lm * draft-lanz-cicm-mm * draft-lanz-cicm-km * draft-lanz-cicm-cm = Goals and Milestones = TBD WGLC on draft-lanz-cicm-lm TBD WGLC on draft-lanz-cicm TBD WGLC on draft-lanz-cicm-mm TBD WGLC on draft-lanz-cicm-km TBD Submit draft-lanz-cicm to the IESG as Proposed Standard _______________________________________________ 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
