The email client extended package (EP) hasn’t received much attention since it came out. Originally released as a stand-alone protection profile (PP) in 2014, it was rewritten as an EP for the Application Software PP in 2015. At this point it has been out for over a year without any evaluations on the Product Compliant List (PCL) or in evaluation. For vendors who are considering an evaluation against this EP but who may have only a passing familiarity with Common Criteria some of its requirements may seem unusual. A closer look at the email EP’s more unique SFRs shows that they should not be unreasonably challenging to test and vendors with compliant products and a business case for certification should not be driven away by unfamiliar terminology.
An unusual threat that the email client EP addresses is that of bad third-party utilities or tools, which in the EP is called T.FLAWED_ADDON. This sounds like it may be a challenge to address, but the requirements of the security functional requirements (SFRs) associated with this threat are quite modest. FPT_AON_EXT.1 and .2 simply verify that if the TOE can use add-ons that those add-ons are authorized and digitally signed. One possible challenge is that one of the testing assurance activities associated with these SFRs is a test where an attempt is made to load add-ons that are modified and improperly signed. These tests would be easy to perform on an email client that runs on a standard desktop operating system. On a more restricted mobile operating system it may not be as straightforward to load a modified add on and carrying out these tests may require developer access.
Another unique SFR in the email client EP is FCS_SMIME_EXT.1. This is not something that’s frequently tested in US Common Criteria evaluations but the requirements of the SFR are fairly straightforward. The testing largely involves sending signed messages between clients, but does require the ability to perform man-in-the-middle attack on messages as they are being transmitted. This is the only SFR in the EP that requires packet modification capabilities.
A number of the email client EP’s other unique SFRs have only documentation based assurance activities. Others that have testing AAs only require an evaluator to use the product’s standard functionality that should be available to any user. FDP_NOT_EXT.1 (S/MIME status notification) can be tested entirely by sending different and receiving different types of emails.
Any client looking to evaluate a product against the email client EP would be well advised to first perform a proper gap analysis, however the EP’s requirements for both the vendor and the testing lab are relatively modest compared to those of the base PP that the EP adds on to.