CON + INT req

    - keyUsage;

    - basicConstraints;

    - certificatePolicies.

  - RATIONALE:

  - RATIONALE: TODO

  - APPLICABILITY: All use cases.

- REFERENCE: REQ-PKI-EMM-05

    - keyUsage;

    - basicConstraints;

    - certificatePolicies.

  - RATIONALE: Only valid certifcates as defined by the product service provider policies shall be generated by the product.

  - APPLICABILITY: All use cases.

- REFERENCE: REQ-PKI-EMM-06

### 6.6.2 CON - Key management

- REFERENCE: ACC-PKI-CON-10

- REFERENCE: ACC-PKI-CON-05

  - OBJECTIVE:

    Verify that exported private or symmetric keys are protected against disclosure using cryptographic mechanisms conforming to Annex K.

  - PREPARATION:

    - Key inspection results.

    - Test reports.

- REFERENCE: ACC-PKI-CON-06

  - OBJECTIVE:

    - Verify that secret keys are never persistently stored in plaintext and are protected by secure cryptographic devices or encryption mechanisms using independently managed keys.

  - PREPARATION:

    - Key management and storage architecture documentation.

    - Database and filesystem documentation.

    - Access to storage repositories and backup media.

    - (If possible) Known private key content

  - ACTIVITIES:

    - Identify all locations where secret keys may be stored.

    - Review storage mechanisms and encryption methods.

    - Inspect storage locations, backups, and configuration files for plaintext secret keys.

    - Verify that keys stored outside secure cryptographic devices are encrypted using approved mechanisms.

    - Verify that plaintext key access occurs only temporarily during cryptographic operations.

  - VERDICT:

    - SUCCESS:

      - Secret keys are never persistently stored in plaintext.

      - Stored keys are protected by secure cryptographic devices or approved encryption mechanisms.

      - Plaintext access is temporary and limited to operational requirements.

    - FAIL:

      - Secret keys are persistently stored in plaintext.

      - Encryption mechanisms do not comply with Annex K.

      - Plaintext key exposure exceeds operational requirements.

  - EVIDENCE:

    - Architecture documentation.

    - Storage configuration files.

    - Database and filesystem inspection results.

    - Backup inspection results.

    - Key management procedures.

## 6.7 Integrity

Assessment requirements covering Monitoring are presented in section 6.13.

The validity of the cryptographic mechanisms used to encure those funtions is covered by annex K assessment requirement.

- REFERENCE: ACC-PKI-INT-01

  - OBJECTIVE:

    - Verify that unauthorized modifications to stored audit records are detected using cryptographic integrity mechanisms conforming to Annex K.

  - PREPARATION:

    - Audit architecture documentation.

    - Integrity protection mechanism specifications.

    - Prepare access to test audit records.

  - ACTIVITIES:

    - Generate audit records.

    - Modify stored audit records without authorization.

    - Execute integrity verification procedures.

    - Verify that modifications are detected and reported.

    - Verify that intergrity mechanisms are conform to Annex assessment requirements.

  - VERDICT:

    - SUCCESS: Unauthorized modifications are reliably detected.

    - FAIL: Unauthorized modifications remain undetected.

  - EVIDENCE:

    - Audit configuration.

    - Integrity verification reports.

    - Tampered audit records.

    - System logs.

## 6.8 Data minimisation

### 6.8.1 General

  - Assessment records.

- REFERENCE: ACC-PKI-SBDC-06

  - OBJECTIVE:

  - Determine whether secret keys are protected against persistent plaintext storage and are exposed in plaintext only temporarily for authorised cryptographic operations.

  - PREPARATION:

  - Obtain key management architecture documentation.

  - Obtain storage architecture documentation.

  - Obtain cryptographic configuration information.

  - Identify all secret key types and storage locations.

  - ACTIVITIES:

  1. Review the product's key management design.

  2. Identify all locations where secret keys may reside.

  3. Verify that secret keys are stored only within an SCD or encrypted using approved algorithms and independently managed keys.

  4. Verify that plaintext secret keys are not persistently stored.

  5. Verify that plaintext exposure is temporary and limited to individual operations or authorised batches of operations.

  6. Review memory handling and key destruction procedures.

  - VERDICT:

    - SUCCESS:

    - Secret keys are never persistently stored in plaintext.

    - Secret keys are stored within an SCD or protected using approved encryption mechanisms and independently managed keys.

    - Plaintext key exposure is temporary and operationally limited.

    - FAIL:

    - Secret keys are persistently stored in plaintext.

    - Keys are stored using unapproved protection mechanisms.

    - Plaintext keys remain accessible beyond authorised operations.

  - EVIDENCE:

  - Key management architecture documentation.

  - Storage architecture and configuration documentation.

  - Cryptographic specifications.

  - Source code review records, if available.

  - Memory analysis and test results.

  - Assessment records demonstrating key handling and destruction procedures.

### 6.8.2 Secret management

- REFERENCE: ACC_PKI_DM_03