Provide the location of the issue
Anywhere the listed SFRs are referenced in the PP/SD
What is the enhancement request for the cPP? Please describe.
The following extended SFRs could be considered for updates into Part 2 SFRs (APE_ECD.1-13 requires extended components to be defined in such a way that they should only be used when the functionality cannot be expressed with existing components).
o FCS_STG_EXT.1.5 becomes FAU_STG.5
o FCS_RBG_EXT.1.1 becomes FCS_RBG.1
o FCS_RBG_EXT.1.2 becomes some combination of FCS_RNG.1 and FCS_RBG.3, .4, and .5. If the latter three are added, they would likely need to be classified as implementation-based requirements depending on how the TOE seeds its DRBG (single source (.3) or multiple sources (.4) that are combined using some function to derive the seed (.5)).
o Arguably, FIA_PMG_EXT.1 could be defined as FIA_SOS.1 rather than creating an extended SFR for this behavior. It doesn’t need to be explicitly justified in the PP itself but there should be a reason a Part 2 SFR was not used here to show APE_ECD.1-13 is satisfied.
o Arguably, FIA_UIA_EXT.1 could be defined as a combination of FIA_UAU.1, FIA_UID.1, and FIA_UAU.5. It doesn’t need to be explicitly justified in the PP itself but there should be a reason a Part 2 SFR was not used here to show APE_ECD.1-13 is satisfied.
Describe the solution you'd like
See above
Describe alternatives you've considered
For those where there is no obvious mapping (i.e. the last two) it would be sufficient for the PP author to justify why Part 2 SFRs were not the best choice.
Additional context
NIAP requested review of PP/SD against CC:2022 and for us to provide guidance and recommendations on changes that will be needed for compatibility with the updated version of the CC.
Provide the location of the issue Anywhere the listed SFRs are referenced in the PP/SD
What is the enhancement request for the cPP? Please describe. The following extended SFRs could be considered for updates into Part 2 SFRs (APE_ECD.1-13 requires extended components to be defined in such a way that they should only be used when the functionality cannot be expressed with existing components). o FCS_STG_EXT.1.5 becomes FAU_STG.5 o FCS_RBG_EXT.1.1 becomes FCS_RBG.1 o FCS_RBG_EXT.1.2 becomes some combination of FCS_RNG.1 and FCS_RBG.3, .4, and .5. If the latter three are added, they would likely need to be classified as implementation-based requirements depending on how the TOE seeds its DRBG (single source (.3) or multiple sources (.4) that are combined using some function to derive the seed (.5)). o Arguably, FIA_PMG_EXT.1 could be defined as FIA_SOS.1 rather than creating an extended SFR for this behavior. It doesn’t need to be explicitly justified in the PP itself but there should be a reason a Part 2 SFR was not used here to show APE_ECD.1-13 is satisfied. o Arguably, FIA_UIA_EXT.1 could be defined as a combination of FIA_UAU.1, FIA_UID.1, and FIA_UAU.5. It doesn’t need to be explicitly justified in the PP itself but there should be a reason a Part 2 SFR was not used here to show APE_ECD.1-13 is satisfied.
Describe the solution you'd like See above
Describe alternatives you've considered For those where there is no obvious mapping (i.e. the last two) it would be sufficient for the PP author to justify why Part 2 SFRs were not the best choice.
Additional context NIAP requested review of PP/SD against CC:2022 and for us to provide guidance and recommendations on changes that will be needed for compatibility with the updated version of the CC.