add namespace to Auditable_Events_for_Mandatory_SFRs

s-choudhury · web-flow · commit b300cd4c0d73 · 2025-03-20T22:24:56.000-04:00
diff --git a/input/mobile-device.xml b/input/mobile-device.xml
@@ -676,7 +676,7 @@ The scope of this Protection Profile (PP) is to describe the security functional
   <sec:req  title="Security Requirements">
     <!-- 5.1 Security Functional Requirements-->
     <sec:SFRs title="Security Functional Requirements">
-      <Auditable_Events_for_Mandatory_SFRs><audit-table table="mandatory" id="t-audit-mandatory"></audit-table><audit-table table="additional" id="t-audit-additional" title="Additional Audit Events"></audit-table><!-- <external-doc ref="pkg-tls"> <audit-event table="additional" ref-cc-id="FCS_DTLS_EXT.1"> <audit-event-descr>Failure of the certificate validity check</audit-event-descr> <audit-event-info>Issuer Name and Subject Name of certificate</audit-event-info> </audit-event> <audit-event table="additional" ref-cc-id="FCS_TLS_EXT.1"> <audit-event-descr>Establishment/termination of a TLS session</audit-event-descr> <audit-event-info>Non-TOE endpoint of connection</audit-event-info> </audit-event> <audit-event table="additional" ref-cc-id="FCS_TLS_EXT.1"> <audit-event-descr>Failure to establish a TLS session</audit-event-descr> <audit-event-info>Reason for failure</audit-event-info> </audit-event> <audit-event table="additional" ref-cc-id="FCS_TLS_EXT.1"> <audit-event-descr>Failure to verify presented identifier</audit-event-descr> <audit-event-info>Presented identifier and reference identifier</audit-event-info> </audit-event> </external-doc> --></Auditable_Events_for_Mandatory_SFRs>
+      <sec:Auditable_Events_for_Mandatory_SFRs><audit-table table="mandatory" id="t-audit-mandatory"></audit-table><audit-table table="additional" id="t-audit-additional" title="Additional Audit Events"></audit-table><!-- <external-doc ref="pkg-tls"> <audit-event table="additional" ref-cc-id="FCS_DTLS_EXT.1"> <audit-event-descr>Failure of the certificate validity check</audit-event-descr> <audit-event-info>Issuer Name and Subject Name of certificate</audit-event-info> </audit-event> <audit-event table="additional" ref-cc-id="FCS_TLS_EXT.1"> <audit-event-descr>Establishment/termination of a TLS session</audit-event-descr> <audit-event-info>Non-TOE endpoint of connection</audit-event-info> </audit-event> <audit-event table="additional" ref-cc-id="FCS_TLS_EXT.1"> <audit-event-descr>Failure to establish a TLS session</audit-event-descr> <audit-event-info>Reason for failure</audit-event-info> </audit-event> <audit-event table="additional" ref-cc-id="FCS_TLS_EXT.1"> <audit-event-descr>Failure to verify presented identifier</audit-event-descr> <audit-event-info>Presented identifier and reference identifier</audit-event-info> </audit-event> </external-doc> --></sec:Auditable_Events_for_Mandatory_SFRs>
       <!--5.1.1 Class: Security Audit (FAU)-->
       <section id="fau" title="Class: Security Audit (FAU)">
         <!--FAU_GEN.1 Audit Data Generation-->
@@ -7487,7 +7487,7 @@ The evaluator shall exercise the TSF configuration as the administrator and
       </section>
     </section>
   </sec:req>
-  <appendix title="Implicitly Satisfied Requirements" id="satisfiedreqs"><htm:table><htm:tr><th>Requirement</th><th>Rationale for Satisfaction</th></htm:tr><htm:tr><htm:td>FAU_SEL.1 - Selective Audit</htm:td><htm:td>FAU_SEL.1 has a dependency on FMT_MTD.1 since configuration of audit data is a subset of managing TSF data. This dependency is met by FMT_SMF.1, which defines "configure the auditable items" as a management function and specifies the roles that may perform this, consistent with how FMT_MTD.1 would typically satisfy the dependency.</htm:td></htm:tr><htm:tr><htm:td>FCS_CKM.1 - Cryptographic Key Generation</htm:td><htm:td>FCS_CKM.1 has a dependency on FCS_CKM.4 for the subsequent destruction of any keys that the TSF generates. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose.</htm:td></htm:tr><htm:tr><htm:td>FCS_CKM.1 - Cryptographic Key Generation</htm:td><htm:td>FCS_CKM.1 has a dependency on FCS_CKM.4 for the subsequent destruction of any keys that the TSF generates. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose as its CC Part 2 equivalent.</htm:td></htm:tr><htm:tr><htm:td>FCS_CKM.2 - Cryptographic Key Establishment</htm:td><htm:td>Both iterations of FCS_CKM.2 have a dependency on FCS_CKM.4 for the subsequent destruction of any keys that the TSF establishes. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose as its CC Part 2 equivalent.</htm:td></htm:tr><htm:tr><htm:td>FCS_COP.1 - Cryptographic Operation</htm:td><htm:td>All iterations of FCS_COP.1 have a dependency on FCS_CKM.4 for the subsequent destruction of any residual key material the TSF creates as part of the operation. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose as its CC Part 2 equivalent.</htm:td></htm:tr><!-- <htm:tr> <htm:td>FCS_HTTPS_EXT.1 - HTTPS Protocol</htm:td> <htm:td>FCS_HTTPS_EXT.1 has a dependency on FMT_SMF.1 for management of the TOE's behavior in the event of an invalid certificate. This dependency is met by the extended SFR FMT_SMF_EXT.1 (specifically function 23), which serves the same purpose as its CC Part 2 equivalent.</htm:td> </htm:tr> --><htm:tr><htm:td>FCS_STG_EXT.1 - Cryptographic Key Storage</htm:td><htm:td>FCS_STG_EXT.1 has a dependency on FMT_SMR.1 for the management roles that are authorized to manage the functionality defined by the requirement. This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF.</htm:td></htm:tr><htm:tr><htm:td>FDP_ACF_EXT.1 - Access Control for System Services</htm:td><htm:td>FDP_ACF_EXT.1 has a dependency on FMT_SMR.1 for the management roles that are authorized to manage the functionality defined by the requirement. This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF.</htm:td></htm:tr><htm:tr><htm:td>FDP_ACF_EXT.2 - Access Control for System Resources</htm:td><htm:td>FDP_ACF_EXT.2 has a dependency on FMT_SMR.1 for the management roles that are authorized to manage the functionality defined by the requirement. This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF.</htm:td></htm:tr><htm:tr><htm:td>FIA_AFL_EXT.1 - Authentication Failure Handling</htm:td><htm:td>FIA_AFL_EXT.1 has a dependency on FIA_UAU.1 since handling of authentication failures is not possible without an authentication mechanism. This dependency is met by the extended SFR FIA_UAU_EXT.1, which serves the same purpose as its CC Part 2 equivalent.</htm:td></htm:tr><htm:tr><htm:td>FIA_PMG_EXT.1 - Password Management</htm:td><htm:td>FIA_PMG_EXT.1 has a dependency on FIA_UAU.1 since composition of authentication credentials is not possible without an authentication mechanism. This dependency is met by the extended SFR FIA_UAU_EXT.1, which serves the same purpose as its CC Part 2 equivalent.</htm:td></htm:tr><htm:tr><htm:td>FIA_UAU.7 - Protected Authentication Feedback</htm:td><htm:td>FIA_UAU.7 has a dependency on FIA_UAU.1 since protected authentication feedback is not possible without an authentication mechanism. This dependency is met by the extended SFR FIA_UAU_EXT.1, which serves the same purpose as its CC Part 2 equivalent.</htm:td></htm:tr><htm:tr><htm:td>FMT_SMF_EXT.3 - Current Administrator</htm:td><htm:td>FMT_SMF_EXT.3 has a dependency on FMT_SMR.1 through its reference to management roles in the requirement text. This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF.</htm:td></htm:tr></htm:table></appendix>
+  <appendix title="Implicitly Satisfied Requirements" id="satisfiedreqs"><htm:table><htm:tr><htm:th>Requirement</htm:th><htm:th>Rationale for Satisfaction</htm:th></htm:tr><htm:tr><htm:td>FAU_SEL.1 - Selective Audit</htm:td><htm:td>FAU_SEL.1 has a dependency on FMT_MTD.1 since configuration of audit data is a subset of managing TSF data. This dependency is met by FMT_SMF.1, which defines "configure the auditable items" as a management function and specifies the roles that may perform this, consistent with how FMT_MTD.1 would typically satisfy the dependency.</htm:td></htm:tr><htm:tr><htm:td>FCS_CKM.1 - Cryptographic Key Generation</htm:td><htm:td>FCS_CKM.1 has a dependency on FCS_CKM.4 for the subsequent destruction of any keys that the TSF generates. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose.</htm:td></htm:tr><htm:tr><htm:td>FCS_CKM.1 - Cryptographic Key Generation</htm:td><htm:td>FCS_CKM.1 has a dependency on FCS_CKM.4 for the subsequent destruction of any keys that the TSF generates. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose as its CC Part 2 equivalent.</htm:td></htm:tr><htm:tr><htm:td>FCS_CKM.2 - Cryptographic Key Establishment</htm:td><htm:td>Both iterations of FCS_CKM.2 have a dependency on FCS_CKM.4 for the subsequent destruction of any keys that the TSF establishes. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose as its CC Part 2 equivalent.</htm:td></htm:tr><htm:tr><htm:td>FCS_COP.1 - Cryptographic Operation</htm:td><htm:td>All iterations of FCS_COP.1 have a dependency on FCS_CKM.4 for the subsequent destruction of any residual key material the TSF creates as part of the operation. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose as its CC Part 2 equivalent.</htm:td></htm:tr><!-- <htm:tr> <htm:td>FCS_HTTPS_EXT.1 - HTTPS Protocol</htm:td> <htm:td>FCS_HTTPS_EXT.1 has a dependency on FMT_SMF.1 for management of the TOE's behavior in the event of an invalid certificate. This dependency is met by the extended SFR FMT_SMF_EXT.1 (specifically function 23), which serves the same purpose as its CC Part 2 equivalent.</htm:td> </htm:tr> --><htm:tr><htm:td>FCS_STG_EXT.1 - Cryptographic Key Storage</htm:td><htm:td>FCS_STG_EXT.1 has a dependency on FMT_SMR.1 for the management roles that are authorized to manage the functionality defined by the requirement. This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF.</htm:td></htm:tr><htm:tr><htm:td>FDP_ACF_EXT.1 - Access Control for System Services</htm:td><htm:td>FDP_ACF_EXT.1 has a dependency on FMT_SMR.1 for the management roles that are authorized to manage the functionality defined by the requirement. This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF.</htm:td></htm:tr><htm:tr><htm:td>FDP_ACF_EXT.2 - Access Control for System Resources</htm:td><htm:td>FDP_ACF_EXT.2 has a dependency on FMT_SMR.1 for the management roles that are authorized to manage the functionality defined by the requirement. This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF.</htm:td></htm:tr><htm:tr><htm:td>FIA_AFL_EXT.1 - Authentication Failure Handling</htm:td><htm:td>FIA_AFL_EXT.1 has a dependency on FIA_UAU.1 since handling of authentication failures is not possible without an authentication mechanism. This dependency is met by the extended SFR FIA_UAU_EXT.1, which serves the same purpose as its CC Part 2 equivalent.</htm:td></htm:tr><htm:tr><htm:td>FIA_PMG_EXT.1 - Password Management</htm:td><htm:td>FIA_PMG_EXT.1 has a dependency on FIA_UAU.1 since composition of authentication credentials is not possible without an authentication mechanism. This dependency is met by the extended SFR FIA_UAU_EXT.1, which serves the same purpose as its CC Part 2 equivalent.</htm:td></htm:tr><htm:tr><htm:td>FIA_UAU.7 - Protected Authentication Feedback</htm:td><htm:td>FIA_UAU.7 has a dependency on FIA_UAU.1 since protected authentication feedback is not possible without an authentication mechanism. This dependency is met by the extended SFR FIA_UAU_EXT.1, which serves the same purpose as its CC Part 2 equivalent.</htm:td></htm:tr><htm:tr><htm:td>FMT_SMF_EXT.3 - Current Administrator</htm:td><htm:td>FMT_SMF_EXT.3 has a dependency on FMT_SMR.1 through its reference to management roles in the requirement text. This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF.</htm:td></htm:tr></htm:table></appendix>
   <appendix title="Entropy Documentation And Assessment" id="entropy">The documentation of the entropy source should be detailed enough that, after reading, the evaluator will thoroughly understand the entropy source and why it can be relied upon to provide entropy. This documentation should include multiple detailed sections: design description, entropy justification, operating conditions, and health testing. This documentation is not required to be part of the TSS.<section id="description" title="Design Description">Documentation shall include the design of the entropy source as a whole, including the interaction of all entropy source components. It will describe the operation of the entropy source to include how it works, how entropy is produced, and how unprocessed (raw) data can be obtained from within the entropy source for testing purposes. The documentation should walk through the entropy source design indicating where the random comes from, where it is passed next, any post-processing of the raw outputs (hash, XOR, etc.), if/where it is stored, and finally, how it is output from the entropy source. Any conditions placed on the process (e.g., blocking) should also be described in the entropy source design. Diagrams and examples are encouraged.<htm:br/><htm:br/><htm:br/><htm:br/>This design must also include a description of the content of the security boundary of the entropy source and a description of how the security boundary ensures that an adversary outside the boundary cannot affect the entropy rate.<htm:br/><htm:br/><htm:br/><htm:br/>If implemented, the design description shall include a description of how third-party applications can add entropy to the RBG. A description of any RBG state saving between power-off and power-on shall be included.</section><section id="justification" title="Entropy Justification">There should be a technical argument for where the unpredictability in the source comes from and why there is confidence in the entropy source exhibiting probabilistic behavior (an explanation of the probability distribution and justification for that distribution given the particular source is one way to describe this). This argument will include a description of the expected entropy rate and explain how you ensure that sufficient entropy is going into the TOE randomizer seeding process. This discussion will be part of a justification for why the entropy source can be relied upon to produce bits with entropy.<htm:br/><htm:br/><htm:br/><htm:br/>The entropy justification shall not include any data added from any third-party application or from any state saving between restarts.</section><section id="conditions" title="Operating Conditions">Documentation will also include the range of operating conditions under which the entropy source is expected to generate random data. It will clearly describe the measures that have been taken in the system design to ensure the entropy source continues to operate under those conditions. Similarly, documentation shall describe the conditions under which the entropy source is known to malfunction or become inconsistent. Methods used to detect failure or degradation of the source shall be included.</section><section id="testing" title="Health Testing">More specifically, all entropy source health tests and their rationale will be documented. This will include a description of the health tests, the rate and conditions under which each health test is performed (e.g., at startup, continuously, or on-demand), the expected results for each health test, and rationale indicating why each test is believed to be appropriate for detecting one or more failures in the entropy source.</section></appendix>
   <appendix title="Acknowledgments" id="ack"><after_bib></after_bib>This protection profile was developed by the Mobility Technical Community with representatives from industry, U.S. Government agencies, Common Criteria Test Laboratories, and international Common Criteria schemes. The National Information Assurance Partnership wishes to acknowledge and thank the members of this group whose dedicated efforts contributed significantly to the publication. These organizations include:<htm:br/><htm:br/><htm:br/><htm:br/><htm:b>U.S. Government</htm:b><htm:br/><htm:br/>Defense Information Systems Agency (DISA)<htm:br/><htm:br/>CyberSecurity Directorate (CSD)<htm:br/><htm:br/>National Information Assurance Partnership (NIAP)<htm:br/><htm:br/>National Institute of Standards and Technology (NIST)<htm:br/><htm:br/><htm:br/><htm:br/><htm:b>International Common Criteria Schemes</htm:b><htm:br/><htm:br/>Australian Information Security Evaluation Program (AISEP)<htm:br/><htm:br/>Canadian Common Criteria Evaluation and Certification Scheme (CSEC)<htm:br/><htm:br/>Information-technology Promotion Agency, Japan (IPA)<htm:br/><htm:br/>UK IT Security Evaluation and Certificate Scheme (NCSC)<htm:br/><htm:br/><htm:br/><htm:br/><htm:b>Industry</htm:b><htm:br/><htm:br/>Apple, Inc.<htm:br/><htm:br/>BlackBerry<htm:br/><htm:br/>LG Electronics, Inc.<htm:br/><htm:br/>Microsoft Corporation<htm:br/><htm:br/>Motorola Solutions<htm:br/><htm:br/>Samsung Electronics Co., Ltd.<htm:br/><htm:br/>Other Members of the Mobility Technical Community<htm:br/><htm:br/><htm:br/><htm:br/><htm:b>Common Criteria Test Laboratories</htm:b><htm:br/><htm:br/>EWA-Canada, Ltd.<htm:br/><htm:br/>Gossamer Security Solutions<htm:br/><htm:br/></appendix>
   <bibliography>
