Update file EN-304-624.md

# 5  Requirements for PKI products

## 5.1 Auditing

REFERENCE: 	REQ-5.1-01

- REFERENCE: 	REQ-5.1-01

REQUIREMENT: The PKI shall record within each audit record at least the following information:

a) Date and time of the event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event; and

b) For each audit event type, based on the auditable event definitions in TODO, the additional information specified in TODO.

EXAMPLES:

APPLICABILITY:

REFERENCE: 	REQ-5.1-02

- REFERENCE: 	REQ-5.1-02

REQUIREMENT: The PKI shall employ reliable time stamps.

RATIONALE:

NOTE:

EXAMPLES:

APPLICABILITY:

REFERENCE: REQ-5.1-03

- REFERENCE: REQ-5.1-03

REQUIREMENT: For audit events resulting from actions of identified users, the PKI shall be able to associate each auditable event with the identity of the user that caused the event.

RATIONALE:

NOTE:

EXAMPLES:

APPLICABILITY:

REFERENCE: REQ-5.1-04

- REFERENCE: REQ-5.1-04

REQUIREMENT: The PKI shall protect the stored audit records in the audit log from unauthorised deletion.

RATIONALE:

NOTE:

EXAMPLES:

APPLICABILITY:

REFERENCE: REQ-5.1-05

- REFERENCE: REQ-5.1-05

REQUIREMENT: The PKI shall be able to detect unauthorised modifications to the stored audit records during the audit.

RATIONALE:

NOTE:

EXAMPLES:

APPLICABILITY:

REFERENCE: REQ-5.1-06

- REFERENCE: REQ-5.1-06

REQUIREMENT: The PKI shall prevent auditable events, except those taken by the auditor, if the audit log is full.

RATIONALE: The audit log being full should not allow for old audit records to be lost or future auditable events to happen without record.

NOTE:

EXAMPLES:

APPLICABILITY:

REFERENCE: REQ-5.1-07

- REFERENCE: REQ-5.1-07

REQUIREMENT: The PKI shall periodically create an audit log signing event in which it computes a

digital signature, keyed hash, or authentication code over the entries in the audit log. The digital signature,

keyed hash, or authentication code shall be computed over, at least, :

EXAMPLES:

APPLICABILITY:

REFERENCE: REQ-5.1-08

- REFERENCE: REQ-5.1-08

REQUIREMENT: The specified frequency at which the audit log signing event occurs shall be configurable.

RATIONALE:

NOTE:

## 5.2 Secret management

TODO: (cannot apply to ALL created keys)

	REFERENCE: 

	- REFERENCE: 

	REQUIREMENT: The PKI shall only create key pairs or symmetric keys by means of a secure cryptographic device appropriate for this use.

	RATIONALE:

	NOTE:

	EXAMPLES:

	APPLICABILITY:

REFERENCE: REQ-5.1.5.2-02

- REFERENCE: REQ-5.1.5.2-02

REQUIREMENT: The PKI shall not persistently store private or symmetric keys in plaintext form.

RATIONALE:

NOTE: The PKI may store private keys in a secure cryptograhic device.

EXAMPLES:

APPLICABILITY:

REFERENCE: REQ-5.1.5.2-03

- REFERENCE: REQ-5.1.5.2-03

REQUIREMENT: Public keys stored within the PKI, but not within a secure cryptographic device, shall be protected against undetected modification through the use of digital signatures, keyed hashes, or authentication codes.

The digital signature, keyed hash, or authentication code used to protect a public key shall be verified upon each access to the key. If verification fails, the PKI shall not:

a) release the accessed public key to the caller; or

EXAMPLES:

APPLICABILITY:

REFERENCE: REQ-5.1.5.2-04

- REFERENCE: REQ-5.1.5.2-04

REQUIREMENT: The PKI shall zeroize secrets in plaintext form.

RATIONALE:

NOTE:

EXAMPLES:

APPLICABILITY: Where the PKI temporarily manipulates secrets in plaintext form.

REFERENCE: REQ-5.1.5.2-05

- REFERENCE: REQ-5.1.5.2-05

REQUIREMENT: The PKI shall not export private or symmetric keys in plaintext form.

RATIONALE: A secret key should not be compromised if its exported form is intercepted.

NOTE: The form of the exported private or symmetric key shall follow state of the art techniques guaranteeing its confidentiality.

## 5.3 Certificate issuance

REFERENCE: REQ-5.1.5.3-01

- REFERENCE: REQ-5.1.5.3-01

REQUIREMENT: The certificates issued by the certificate generation service shall be public-key certificates or attribute certificates whose format complies with the X.509 standard [ITU-T X.509].

RATIONALE:

NOTE:

EXAMPLES:

APPLICABILITY: Where the PKI has a certificate generation service.

REFERENCE: REQ-5.1.5.3-02

- REFERENCE: REQ-5.1.5.3-02

REQUIREMENT: The certificates issued by the certificate generation service shall be public-key certificates or attribute certificates whose format complies with the X.509 standard [ITU-T X.509].

RATIONALE: Public-key certificates shall use version 3 certificates since this standard requires the use of certificates extensions.

NOTE: At a minimum, the PKI shall ensure that:

EXAMPLES:

APPLICABILITY: Where the PKI has a certificate generation service, issuing public-key certificates.

REFERENCE: REQ-5.1.5.3-03

- REFERENCE: REQ-5.1.5.3-03

REQUIREMENT: The PKI shall implement a certificate profile and shall ensure that issued certificates are consistent with that profile.

RATIONALE:

NOTE:

EXAMPLES:

APPLICABILITY: Where the PKI has a certificate generation service.

REFERENCE: REQ-5.1.5.3-04

- REFERENCE: REQ-5.1.5.3-04

REQUIREMENT: The PKI shall require the Administrator to specify the set of acceptable values for the following fields and extensions:

a) the authority key identifier;

b) the algorithm identifier for the subject’s public/private key pair;

EXAMPLES:

APPLICABILITY: Where the PKI has a certificate generation service, issuing public-key certificates.

REFERENCE: REQ-5.1.5.3-05

- REFERENCE: REQ-5.1.5.3-05

REQUIREMENT: The PKI shall require the Administrator to specify the set of acceptable values for the following fields and extensions:

a) keyUsage;

b) basicConstraints;

EXAMPLES:

APPLICABILITY: Where the PKI has a certificate generation service, issuing public-key certificates.

REFERENCE: REQ-5.1.5.3-06

- REFERENCE: REQ-5.1.5.3-06

REQUIREMENT: The PKI shall mark the following extensions as critical:

a) keyUsage;

b) basicConstraints;

EXAMPLES:

APPLICABILITY: Where the PKI has a certificate generation service, issuing public-key certificates.

REFERENCE: REQ-5.1.5.3-07

- REFERENCE: REQ-5.1.5.3-07

REQUIREMENT: The PKI shall disallow the keyUsage extension to simultaneously include values from both of:

a) digitalSignature, contentCommitment, keyCertSign, cRLSign; and

b) keyEncipherment, dataEncipherment, keyAgreement.

EXAMPLES:

APPLICABILITY: Where the PKI has a certificate generation service, issuing public-key certificates.

REFERENCE: REQ-5.1.5.3-08

- REFERENCE: REQ-5.1.5.3-08

REQUIREMENT: The PKI shall verify that the prospective certificate subject possesses the private key that

corresponds to the public key in the certificate request before issuing a certificate, unless the public/private key pair

was generated by the PKI and never left the certificate issuance service.

## 5.4 Certificate status

REFERENCE: REQ-5.1.5.4-01

- REFERENCE: REQ-5.1.5.4-01

REQUIREMENT: The certificate status service shall provide certificate revocation statuses as either or both of:

a) CRLs as defined by and subject to the requirements of [ITU-T X.509]; or

b) OCSP responses to OCSP requests as defined by and subject to the requirements of [RFC 6960].

EXAMPLES:

APPLICABILITY: Where the PKI has a certificate status service.

REFERENCE: REQ-5.1.5.4-02

- REFERENCE: REQ-5.1.5.4-02

REQUIREMENT: The PKI shall implement a CRL profile and shall ensure that issued CRls are consistent with that profile.

RATIONALE:

NOTE:

EXAMPLES:

APPLICABILITY: Where the PKI has a certificate status service, issuing CRLs.

REFERENCE: REQ-5.1.5.4-03

- REFERENCE: REQ-5.1.5.4-03

REQUIREMENT: The PKI shall require the Administrator to specify the set of acceptable values for the following fields and extensions:

a) issuer;

b) issuerAltName;

EXAMPLES:

APPLICABILITY: Where the PKI has a certificate status service, issuing CRLs.

REFERENCE: REQ-5.1.5.4-04

- REFERENCE: REQ-5.1.5.4-04

REQUIREMENT: The PKI shall implement an OCSP response profile and shall ensure that issued OCSP responses are consistent with that profile.

RATIONALE:

NOTE:

EXAMPLES:

APPLICABILITY: Where the PKI has a certificate status service, issuing OCSP responses.

REFERENCE: REQ-5.1.5.4-05

- REFERENCE: REQ-5.1.5.4-05

REQUIREMENT: The PKI shall require the Administrator to specify the set of acceptable values for the responseType field.

RATIONALE:

NOTE:

EXAMPLES:

APPLICABILITY: Where the PKI has a certificate status service, issuing OCSP responses, not restricted to the basic response type.

REFERENCE: REQ-5.1.5.4-06

- REFERENCE: REQ-5.1.5.4-06

REQUIREMENT: The PKI shall require the Administrator to specify the set of acceptable values for the responderID field.

RATIONALE:

NOTE: An OCSP responder is required to be capable to emit OCSP responses of the basic type by [RFC 6960].

APPLICABILITY: Where the PKI has a certificate status service, issuing OCSP responses of the basic response type.

REFERENCE: 

- REFERENCE: 

REQUIREMENT:

RATIONALE:

NOTE:

## 6.1 Auditing

REFERENCE: ASS-REQ-6.1-01

- REFERENCE: ASS-REQ-6.1-01

OBJECTIVE: Verify that the PKI records within each audit record the required information, and that these records do not include any secret key or other secret parameter in plaintext form.

PREPARATION: Ability to trigger auditable events, and ability to audit events.

ACTIVITIES:

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

EVIDENCE: The way the events were triggered and at what time, and the corresponding audit records.

REFERENCE: ASS-REQ-6.1-02

- REFERENCE: ASS-REQ-6.1-02

OBJECTIVE: Verify that the PKI employs reliable time stamps.

PREPARATION: Ability to trigger auditable events, and ability to audit events. Obtain access to a trusted time stamp origin. Determine how the PKI determines its time stamps.

ACTIVITIES: Trigger an auditable event. Access the corresponding audit record. Verify the date and time of the event to match the trusted time stamp origin.

b) arguments relating to the authentication of a trusted source (if applicable);

c) arguments relating to the monotonicity of local time information (if applicable).

REFERENCE: ASS-REQ-6.1-03

- REFERENCE: ASS-REQ-6.1-03

OBJECTIVE: Verify that the PKI records within each audit record resulting from actions of identified users the corresponding user information.

PREPARATION: Ability to identify to the PKI as a given user. Ability to trigger auditable events as a user, and ability to audit events.

ACTIVITIES: Identify to the PKI as the given user. Trigger an auditable event as the given user. Access the corresponding audit record.

a) The identity of the given user used for the test;

a) the way the event was triggered and at what time, and the corresponding audit record.

REFERENCE: ASS-REQ-6.1-04

- REFERENCE: ASS-REQ-6.1-04

OBJECTIVE: Verify PKI protections from unauthorised deletion to be active and functional.

PREPARATION:  Ability to identify to the PKI as a given user, unauthorised to perform audit record deletion. Ability to trigger auditable events as a user, and ability to audit events. Determine all actions that may result in deletion of an audit record. Depending on this list of actions, several distinct users with distinct authorizations may be used.

ACTIVITIES: Identify to the PKI as the given user. Trigger an auditable event as the given user. Access and copy audit records separately.

c) the way the actions were attempted, including the corresponding user identity;

d) the copies of existing audit records, before and after attempts.

REFERENCE: ASS-REQ-6.1-05

- REFERENCE: ASS-REQ-6.1-05

OBJECTIVE: Verify the PKI's ability to detect unauthorised modifications to the stored audit records during the audit.

PREPARATION: Ability to trigger auditable events as a user, and ability to audit events. Ability to directly modify the contents of existing audit records.

ACTIVITIES: Trigger an auditable event. Access and copy the corresponding audit record separately.

b) the way the audit record was directly modified;

c) the way the last audit was attempted, and the corresponding response from the PKI.

REFERENCE: ASS-REQ-6.1-06

- REFERENCE: ASS-REQ-6.1-06

OBJECTIVE: Verify the PKI's prevention of auditable events, except those taken by the auditor, if the audit log is full.

PREPARATION: Ability to trigger auditable events, and ability to audit events. The maximum size of the audit log may be reduced.

ACTIVITIES: Do not identify as an auditor to the PKI. Trigger auditable events until the audit log is full, or nearly so.

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 PKI.

REFERENCE: ASS-REQ-6.1-07

- REFERENCE: ASS-REQ-6.1-07

OBJECTIVE: Verify the use of an audit log signing event by the PKI.

PREPARATION: Ability to trigger auditable events, and ability to audit events.

Determine the configured frequency of the audit log signing event and date of the audit log signing event. The frequency of the audit log signing event may be reduced; the event shall not be triggered manually.

d) the way the audit record of the triggered event was modified;

d) the way the second-to-last signature, keyed hash or authentication code was modified.

REFERENCE: ASS-REQ-6.1-08

- REFERENCE: ASS-REQ-6.1-08

OBJECTIVE: Verify the frequency of the audit log signing event by the PKI to be configurable.

PREPARATION: Ability to trigger auditable events, and ability to audit events. Ability to configure the frequency of the audit log signing event.

ACTIVITIES: Modify the frequency of the audit log signing event.

a) The new frequency which was configured;

b) the 2 last audit log signing events as they appear in the audit log, and their corresponding date and time.

REFERENCE: 

- REFERENCE: 

OBJECTIVE: 

PREPARATION: 

ACTIVITIES: