@@ -1184,8 +1184,7 @@ To limit certificate forgery or misuse of certificate content, this section defi
- REFERENCE: REQ-PKI-EMM-07
- REQUIREMENT: The product shall verify that the prospective certificate subject possesses the private key corresponding to the public key contained in the certificate request by means of a cryptographic challenge (e.g., signature generation or decryption) before issuing a certificate, unless the public/private key pair was generated by the product and has never left the certificate issuance service.
- RATIONALE: A subject bringing forth his own public key should prove ownership of the corresponding private key. The product may generate a key pair and associated public key, and later communicate the private key to the correct subject in a secure manner. This may notably be done for other components of the product itself needing public-key certificates. The same private key should not be owned by distinct subjects, including other services of the product; if the private key was generated by the product but already provided to the subject once, the subject can and should prove its ownership.
- APPLICABILITY: All use cases.
- APPLICABILITY: U2, UC3, UC4, UC5.
### 5.12.2 EMM - Certificate status
@@ -1246,7 +1245,7 @@ To limit certificate forgery or misuse of certificate content, this section defi
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (l).
These requirements are about the collection and handling of "auditable events", that is, particular events happening during the product operations which require to be traced so as to allow an authorised third-party to audit the PKI's operation. A PKI may produce other types of logs that do not fall under these requirements.
These requirements are about the collection and handling of auditable events, that is, particular events happening during the product operations which require to be traced so as to allow an authorised third-party to audit the PKI's operation. A PKI may produce other types of logs that do not fall under these requirements.
- REFERENCE: REQ-PKI-MON-01
- REQUIREMENT: The product shall record events related to all product functions identified for each use case (as defined in Annex U), as well as all privileged user login attempts and product updates.
@@ -2051,7 +2050,7 @@ The validity of the cryptographic mechanisms used to encure those funtions is co
- ACTIVITIES:
- Generate CRLs.
- Inspect the signer identity and signature information.
- Verify that the signer corresponds to a CA (e.g. "basicConstraints" field contains "CA:TRUE") or an authorized delegated entity (certificate with "keyUsage" including "cRLSign").
- Verify that the signer corresponds to a CA (e.g. `basicConstraints` field contains `CA:TRUE`) or an authorized delegated entity (certificate with `keyUsage` including `cRLSign`).
- Validate the digital signature.
- Attempt to validate a CRL modified after signing.
- VERDICT:
@@ -2625,7 +2624,9 @@ As stated in clause 5.10, since minimizing the impact on other systems relies on
- For each way the product may successfully issue a public-key certificate:
- request a certificate;
- verify the issued certificate to contain information allowing a verifier to obtain a CRL or OCSP response.
- VERDICT: SUCCESS if all the verifications pass; else FAIL.
- VERDICT:
- SUCCESS: The product does not issue certificates without a configured revocation mechanism and all issued public-key certificates contain information enabling retrieval of a CRL and/or an OCSP response.
- FAIL: The product issues certificates without a revocation source, or any issued public-key certificate lacks information enabling retrieval of a CRL or OCSP response.
- EVIDENCE:
- The configuration attempts, or other evidence such configuration is not supported;
- the way issuances were requested, and the responses from the product.
@@ -2633,17 +2634,24 @@ As stated in clause 5.10, since minimizing the impact on other systems relies on
- REFERENCE: ACC-PKI-EMM-09
- OBJECTIVE:
- Verify the product implements and enforces a CRL profile for issued CRLs.
- PREPARATION: Ability to request a CRL as certificate status for a given certificate. Document the CRL profile implemented by the product.
- PREPARATION:
- Ability to request a CRL as certificate status for a given certificate.
- Documentation of the CRL profile implemented by the product.
- ACTIVITIES:
- Request a CRL;
- verify the CRL to match the constraints of the CRL profile.
- VERDICT: SUCCESS if all the verifications pass; else FAIL.
- VERDICT:
- SUCCESS: All issued CRLs conform to the documented CRL profile, including all required fields, formats, and constraints, and are successfully validated against the profile.
FAIL: Any issued CRL does not conform to the CRL profile, is missing required elements, or violates any defined constraint in the CRL profile.
- EVIDENCE: The way the CRL was requested, and the response and CRL from the product.
- REFERENCE: ACC-PKI-EMM-10
- OBJECTIVE: Verify that the product requires authorized users to specify the set of acceptable values for the fields and extensions identified in REQ-5.4-03.
- OBJECTIVE: Verify that the product requires authorized users to specify the set of acceptable values for the fields and extensions: issuer, issuerAltName,
nextUpdate.
- PREPARATION: authorized users access to not-installed or reinitialised product, or specifically its certificate status service and related configuration.
- ACTIVITIES: Verify that no CRL may be issued until acceptables values for the issuer, issuerAltName and nextUpdate fields and extensions are set.
- ACTIVITIES:
- Verify that authorized users can modify the `issuer`, `issuerAltName`, `nextUpdate`.
- Verify that no CRL may be issued until acceptables values for the issuer, issuerAltName and nextUpdate fields and extensions are set.
- VERDICT: SUCCESS if the verifications passes; else FAIL.
- EVIDENCE: The way CRLs were requested, and the responses from the product.
@@ -2728,10 +2736,10 @@ REFERENCE: ACC_PKI_MON_02
- Ability to trigger auditable events, and ability to audit events.
- ACTIVITIES: Trigger an auditable event. Access the corresponding audit record.
- Verify the audit record contains at least:
a) the date and time of the event;
b) the type of the event;
c) the subject identity (if applicable);
d) the outcome of the event.
- the date and time of the event;
- the type of the event;
- the subject identity (if applicable);
- 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 by the developper.
- For each information verified to be present, verify it matches the expected value given when and how the event was triggered.
- For each of the generated audit record, verify that no private or symmetric key, as well as no other secret parameter is present in plaintext form.
@@ -2750,9 +2758,9 @@ REFERENCE: ACC_PKI_MON_02
- If the product may increment temporary or long-term time information stored locally, verify that the time information may not be used in data issued by the product until it has been properly been incremented, or alternatively that the service responsible for it cannot fail.
- VERDICT: SUCCESS if all the verifications pass; else FAIL.
- EVIDENCE:
a) The way the events were triggered and at what time, and the corresponding audit records;
b) arguments relating to the authentication of a trusted source (if applicable);
c) arguments relating to the monotonicity of local time information (if applicable).
- The way the events were triggered and at what time, and the corresponding audit records;
- arguments relating to the authentication of a trusted source (if applicable);
- arguments relating to the monotonicity of local time information (if applicable).
- REFERENCE: ACC_PKI_MON_04
- OBJECTIVE:
@@ -2765,8 +2773,8 @@ REFERENCE: ACC_PKI_MON_02
- Verify this identity to match that of the given user.
- VERDICT: SUCCESS if all the verifications pass; else FAIL.
- EVIDENCE:
a) The identity of the given user used for the test;
b) the way the event was triggered and at what time, and the corresponding audit record.
- The identity of the given user used for the test;
- the way the event was triggered and at what time, and the corresponding audit record.
- REFERENCE: ACC_PKI_MON_04
- OBJECTIVE:
@@ -2780,10 +2788,10 @@ REFERENCE: ACC_PKI_MON_02
- Access audit records and verify they match the copy performed previously.
- VERDICT: SUCCESS if the verification passes; else FAIL.
- EVIDENCE:
a) The identity of the given user(s) used for the test;
b) the list of identified actions that may result in deletion of an audit records;
c) the way the actions were attempted, including the corresponding user identity;
d) the copies of existing audit records, before and after attempts.
- The identity of the given user(s) used for the test;
- the list of identified actions that may result in deletion of an audit records;
- the way the actions were attempted, including the corresponding user identity;
- the copies of existing audit records, before and after attempts.
- REFERENCE: ACC_PKI_MON_05
- OBJECTIVE:
@@ -2796,9 +2804,9 @@ REFERENCE: ACC_PKI_MON_02
- Verify that a given additional auditable event may be triggered as the auditor.
- VERDICT: SUCCESS if the verification passes; else FAIL.
- EVIDENCE:
a) The configured maximum size of the audit log;
b) The size of the audit when full, or nearly so;
c) the way the additional event was attempted to be triggered, and the corresponding response from the product.
- The configured maximum size of the audit log;
- the size of the audit when full, or nearly so;
- the way the additional event was attempted to be triggered, and the corresponding response from the product.
- REFERENCE: ACC_PKI_MON_06
- OBJECTIVE:
@@ -2823,11 +2831,11 @@ REFERENCE: ACC_PKI_MON_02
- VERDICT: SUCCESS if all the verifications pass; else FAIL.
- EVIDENCE:
a) The way the auditable event was triggered;
b) the last entries of the audit log, including all the entries impacting the third-to-last audit log signing event and its signature, keyed hash or authentication code;
c) the way the signatures, keyed hashes or authentication codes were verified, and the corresponding responses from the product;
d) the way the audit record of the triggered event was modified;
e) the way the second-to-last signature, keyed hash or authentication code was modified.
- The way the auditable event was triggered;
- the last entries of the audit log, including all the entries impacting the third-to-last audit log signing event and its signature, keyed hash or authentication code;
- the way the signatures, keyed hashes or authentication codes were verified, and the corresponding responses from the product;
- the way the audit record of the triggered event was modified;
- the way the second-to-last signature, keyed hash or authentication code was modified.
