Re: FCS_COP and FCS_CKM interdependency

["NIAP Interpretations Board" <faigin@aero.org>]

The NIB agrees with Dr Out that the FCS classes seem out of place in the CC: 
whereas all other CC classes address security functions that the TOE may 
provide, the topic of FCS (cryptography) is a means that might be employed to 
provide such services. One could imagine cryptography being used to provide 
user data protection, authentication, role separation, or a host of other 
services described in the other classes of Part 2. If a cryptographic solution 
were required, a PP author could  simply refine any of the Part 2 requirements 
to specify cryptography, thereby ignoring the FCS class entirely.

That FCS is different from the others becomes even more apparent when the 
functional requirements are traced back to threats. A threat that a 
communications channel might be observed could trace to the need for the line 
to be encrypted, but there would remain the question of the strength of the 
algorithm relative to the threat. Threats are not usually specified to that 
level of detail for other families (for example, to a level that addresses 
whether permission bits are sufficient to separate user access to data, or 
whether something stronger, such as ACLs, would be required).

The NIB understands that the Part 3 requirements are being revisited and 
updated; it hopes that Part 2 will likewise be corrected and clarified. FCS 
seems a very good place to start.