SFR notes:

At the Lexington meeting, some additional SFRs were proposed. After considering them, I propose these dispositions:

FMT_MOF.1 to fulfill O.ACCESS for PP-A, possible also PP-B or PP-C:
This was recommended for supporting NIAP CIM. I think we should wait on this and handle with other CIM requirements.

FMT_MSA.3 to fulfill O.ACCESS for PP-A|B and maybe PP-C:
I'm not sure why this was proposed. Perhaps we can discuss this in El Segundo. I left it on the spreadsheet, but it's grayed out.

FMT_REV.1 to fulfil O.ACCESS for one or more of the PPs:
This was suggested if what it meant was deleting a user's access. It turns out that it means revocation of rights under conditions like at next login, after a period of time, etc. Doesn't really apply. 

FCS_COP.1 to fulfill O.NETWORK for PP-A (user and mgmt data) and PP-B|C (mgmt data):
I think this is OK, and we already had FCS_COP.1 for PP-A and PP-B to fulfill O.PROTECT. This adds FCS_COP.1 and its dependency SFRs to PP-C. I have added it and its dependencies to O.NETWORK.

FDP_UCT.1 and FDP_UIT.1 to fulfill O.NETWORK for PP-A:
This has to do with more complex cryptographic operations (digital signatures and the like) than we really need to specify. We already have FTP_ITC.1 for trusted channels, it should suffice. ST authors can add this, for example, if they support such operations like with IPsec.

FTP_TRP.1 to fulfill O.NETWORK for PP-A (user and mgmt data) and PP-B|C (mgmt data only) was suggested instead of FTP_ITC.1. TRP is for trusted paths to users, and ITC is for trusted channels to IT devices. I think that we can't really require a trusted path to a walk-up user, and other users would be intermediated by an IT device, so I think that ITC is OK and we should not require TRP in addition to or instead of ITC.

FRU_FLT.1, with its dependency FPT_FLS.1, to fulfill O.RESILIENT:
FLT ensures that some TOE capabilities will continue to operate when specified failures occur. However, the objective O.RESILIENT doesn't require continued operations during a failure, only that it maintains some secure state during and recovers after. FPT_FLS.1 ensures that a secure state is maintained during a failure, but it refers to a failure _in the TSF_. Our T.DOS threats create failures that are more likely outside of the TSF. Alas, I don't think either of these apply. For now, we'll stay with ATE_FUN.1 and not any SFRs.

FTP_ITC.1 to fulfill O.GENUINE for PP-A|B|C:
I think that assuming a trusted channel for applet loads and software updates is reasonable, and it doesn't add any new SFRs to any environments (FTP_ITC.1 was already required for PP-A|B|C to fulfill O.NETWORK).

An explicitly stated SFR to fulfill O.FAXONLY for PP-A|B|C:
(Refer to page 43 of this ST for an example, courtesy of Xerox: http://www.commoncriteriaportal.org/files/epfiles/ST_VID10135-ST.pdf)
I think this is a good solution for an ST, but it is likely to be too specific for a PP. I think we should stay with ADV_ARC.1 and perhaps include a PP app note about including an explicit SFR in STs.

FPR_UNL.1 to fulfill O.FAXONLY for PP-A|B|C (This was suggested after the Lexington meeting ended):
This is part of the Privacy class and has to do with ensuring that different operations can't cooperate in such a way to obtain information that they could not obtain individually. I don't think this applies to our objective.

Final note: there are a few remaining question marks in the SFRworksheet, mostly having to do with whether or not some SFRs are included in PP-C and PP-D. I think we can leave those for later resolution.