This PR might be more controversial than the previous two.
Currently, my understanding is that the glossary in the cPP defines that an RoT for Storage is the combination of an RoT for Confidentiality and an RoT for Integrity. The RoT for Confidentiality means that the DSC protects sensitive data (i.e., SDEs and SDOs) against disclosure. The RoT for Integrity means the DSC protects sensitive data (i.e., SDEs and SDOs) and platform characteristics against tampering. At the very least, it sounds like the RoT for Storage must make sure that secret/private keys remain secret/private and are not modified, and public keys are not modified.
However, this SFR (FPT_ROT_EXT.2) is very vague in the requirements it imposes on the RoT of Storage. It simply says "prevents unauthorized access". The application note refers to "FDP_SDI.2 to protect the integrity of SDOs", but the issue of confidentiality is never addressed.
I propose that this SFR explicitly states that "unauthorized access" includes unauthorized disclosure for SDOs that are supposed to remain secret, and unauthorized modification for every SDO. I think this is a reasonable interpretation, but maybe I'm being too strict. Then in the Application Note, I add FDP_SDC.2 as a way to meet the confidentiality requirements. I think that cryptographic or non-cryptographic ways to maintain confidentiality are both equally suitable.
In the SD, I removed the reference to FSC_CKM.1, because I don't believe these SFRs (key generation) serve any purpose in protecting the security of stored SDOs. Maybe I'm wrong though, so I'd be willing to revert this change. I also added FDP_SDC.2 as a reference for the tests.
Finally, I think "associated with" could be changed to "stored in" to be more explicit. The Application Note already used that usage, so I assume that's the intended meaning. I'd be willing to revert this change too if "associated with" is intended to be broader than "stored in".
The issue of FPT_ROT_EXT.2 will be addressed in a separate PR.
This PR might be more controversial than the previous two.
Currently, my understanding is that the glossary in the cPP defines that an RoT for Storage is the combination of an RoT for Confidentiality and an RoT for Integrity. The RoT for Confidentiality means that the DSC protects sensitive data (i.e., SDEs and SDOs) against disclosure. The RoT for Integrity means the DSC protects sensitive data (i.e., SDEs and SDOs) and platform characteristics against tampering. At the very least, it sounds like the RoT for Storage must make sure that secret/private keys remain secret/private and are not modified, and public keys are not modified.
However, this SFR (FPT_ROT_EXT.2) is very vague in the requirements it imposes on the RoT of Storage. It simply says "prevents unauthorized access". The application note refers to "FDP_SDI.2 to protect the integrity of SDOs", but the issue of confidentiality is never addressed.
I propose that this SFR explicitly states that "unauthorized access" includes unauthorized disclosure for SDOs that are supposed to remain secret, and unauthorized modification for every SDO. I think this is a reasonable interpretation, but maybe I'm being too strict. Then in the Application Note, I add FDP_SDC.2 as a way to meet the confidentiality requirements. I think that cryptographic or non-cryptographic ways to maintain confidentiality are both equally suitable.
In the SD, I removed the reference to FSC_CKM.1, because I don't believe these SFRs (key generation) serve any purpose in protecting the security of stored SDOs. Maybe I'm wrong though, so I'd be willing to revert this change. I also added FDP_SDC.2 as a reference for the tests.
Finally, I think "associated with" could be changed to "stored in" to be more explicit. The Application Note already used that usage, so I assume that's the intended meaning. I'd be willing to revert this change too if "associated with" is intended to be broader than "stored in".
The issue of FPT_ROT_EXT.2 will be addressed in a separate PR.