Commit 1b56de6a authored by Sammy Haddad's avatar Sammy Haddad
Browse files

Update file EN-304-624.md

parent 498c2809
Loading
Loading
Loading
Loading
+45 −10
Original line number Diff line number Diff line
@@ -173,12 +173,14 @@ The following referenced documents are necessary for the application of the pres

- <span id="_ref_1"></span><a name="_ref_1">[1]</a> \"ITU-T X.509\" \"(10/2019)\": \"Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks\"
  - NOTE:	Identical text in the defining of public-key and attribute certificates is also available in ISO/IEC 9594‑8 (paywall).
- Editor's NOTE: the normal convention appears to be to refer to X.509 (as the original source) but in some cases references are cited as ITU‑T X.509/ISO‑IEC 9594‑8. 
  
- <span id="_ref_2"></span><a name="_ref_2">[2]</a> \"prEN 40000-1-3\": \"Cybersecurity requirements for products with digital elements – Vulnerability Handling \" [Version and date to be added upon its publication by CEN CENELEC]

- <span id="_ref_3"></span><a name="_ref_3">[2]</a>ENISA Report 1747792503: “European Cybersecurity Certification Group Sub-group on Cryptography Agreed Cryptographic Mechanisms - version 2” – April 2025
- <span id="_ref_3"></span><a name="_ref_3">[3]</a> \"ENISA Report 1747792503\": “European Cybersecurity Certification Group Sub-group on Cryptography Agreed Cryptographic Mechanisms - version 2” – April 2025

- <span id="_ref_4"></span><a name="_ref_4">[4]</a> "IEEE Std 1609.2™-2022" "(2022)": "Standard for Wireless Access in Vehicular Environments—Security Services for Applications and Management Messages"

- <span id="_ref_5"></span><a name="_ref_5">[5]</a> "ETSI TS 102 941 V1.4.1" "(2021-01)": "Intelligent Transport Systems (ITS); Security; Trust and Privacy Management"

## 2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or nonspecific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.
@@ -1301,7 +1303,24 @@ information shall be recorded, after a proper verification.
   - RATIONALE: Only authorised, identicated and authenticated user should be able to access the PKI services and stored data. This covers threats all threats. 
  - APPLICABILITY: All use cases. 

 ## 5.11 XXX 
 ## 5.11 Secure communication with external entities

  - REFERENCE: REQ-5.10-02
  - REQUIREMENT:
The PKI shall permit an communication between a and the PKI if the following rules hold:
    - The certificates are valid as defined by (6) section 5.1
    - Sending
        ◦ The requests are encrypted and signed as defined by (1) section 6.2.3.4.1 using EA and AA Certificates
        ◦ The Message format is conformant to (1)section 6.2.3.4.1
    - Reception
        ◦ The requests can be correctly decrypted and the signature is valid with respect to the validated EA and AA Certificates
        ◦ The Message format is conformant to (1) section 6.2.3.4.1
].


   - RATIONALE: Only authorised, identicated and authenticated user should be able to access the PKI services and stored data. This covers threats all threats. 
  - APPLICABILITY: All use cases. 


# 6 Conformity Assessment
*Editor's note: This section's structur is stable. The content is not stable.*
@@ -1332,7 +1351,7 @@ Trigger an auditable event. Access the corresponding audit record. Verify the au

    d) the outcome of the event.

Perform the above for each audit event type, and verify that the audit record additionally contains the additional information specified in TODO.
Perform the above for each audit event type, and verify that the audit record additionally contains the additional information specified by the developper.

For each information verified to be present, verify it matches the expected value given when and how the event was triggered.

@@ -1652,13 +1671,29 @@ Ability to request the public key (if applicable). Ability to trigger an action

  - OBJECTIVE: Verify the certificates issued by the certificate generation service are public-key certificates or attribute certificates whose format complies with the X.509 standard [ITU-T X.509].

  - PREPARATION: TODO
  - PREPARATION: 
    - Certificate request interface accessible.
    - Required user profiles defined to generate the certificate.
    - Certificate Policy parameters defined, i.e. PKI configuration realted to configurable certficate generation constraints (e.g. Certificate validaty periode, mandatory Certificate fields and values, etc.)

  - ACTIVITIES: TODO
  - ACTIVITIES:
    - Verify that certficates are correctly generated when correct information is provided.
      - Provide a set of necessary and correct elements defined by the Certificate Policy.
      - Generate, i.e. activate the certificate generation fonction with the correct inputs
      - Verify that a certificate is generated including the inputed data
      - Verify that the signature is correct and cover all the necessary fields
    - Verify that certficates are not generated if inputed data are missing or incorrect related to the Certificate Policy configuratio
      - Provide a set of necessary and correct elements defined by the Certificate Policy.
      - Generate, i.e. activate the certificate generation fonction with the correct inputs
      - Verify that a certificate is generated including the inputed data
      - Verify that the signature is correct and cover all the necessary fields

  - VERDICT: TODO
  - VERDICT:SUCCESS if all the verifications pass; else FAIL.

  - EVIDENCE: TODO
  - EVIDENCE:
    - Certificate generation requests parameters
    - Generated certficates or error messages generated by the PKI
    - Signature verification input and output

- REFERENCE: ASS-REQ-6.4-02