Replacing TSP instances by PKI

##5.1 Auditing

REFERENCE: 	REQ-5.1.5.1-01

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

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.

RATIONALE:

APPLICABILITY:

REFERENCE: 	REQ-5.1.5.1-02

REQUIREMENT: The TSP shall employ reliable time stamps.

REQUIREMENT: The PKI shall employ reliable time stamps.

RATIONALE:

NOTE:

EXAMPLES:

APPLICABILITY:

REFERENCE: REQ-5.1.5.1-03

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

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.5.1-04

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

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

RATIONALE:

NOTE:

EXAMPLES:

APPLICABILITY:

REFERENCE: REQ-5.1.5.1-05

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

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.5.1-06

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

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.5.1-07

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

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, :

a) every entry that has been added to the audit log since the previous audit log signing event;

TODO: (cannot apply to ALL created keys)

	REFERENCE: 

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

	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

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

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

RATIONALE:

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

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

EXAMPLES:

APPLICABILITY:

REFERENCE: REQ-5.1.5.2-03

REQUIREMENT: Public keys stored within the TSP, 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 TSP shall not:

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

b) use the accessed public key.

RATIONALE: Unauthorized modifications of public keys stored by the TSP should not go undetected.

Public keys modified without authorization should not be considered safe for use and not be disseminated throughout or outside the TSP.

RATIONALE: Unauthorized modifications of public keys stored by the PKI should not go undetected.

Public keys modified without authorization should not be considered safe for use and not be disseminated throughout or outside the PKI.

NOTE:

EXAMPLES:

APPLICABILITY:

REFERENCE: REQ-5.1.5.2-04

REQUIREMENT: The TSP shall zeroize secrets in plaintext form.

REQUIREMENT: The PKI shall zeroize secrets in plaintext form.

RATIONALE:

NOTE:

EXAMPLES:

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

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

REFERENCE: REQ-5.1.5.2-05

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

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.

EXAMPLES: The exported private or symmetric key may be encrypted such that only its designated recipient may decrypt it.

RATIONALE:

NOTE:

EXAMPLES:

APPLICABILITY: Where the TSP has a certificate generation service.

APPLICABILITY: Where the PKI has a certificate generation service.

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 TSP shall ensure that:

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

a) the version field shall contain the integer 2;

b) the serialNumber shall be unique with respect to the issuing Certification Authority;

c) the validity field shall specify a notBefore value that does not precede the current time and a notAfter

certificate shall contain a critical subjectAltName extension;

f) the signature field and the algorithm in the subjectPublicKeyInfo field shall designate a recommended agreed signature algorithm [ETSI TS 119 312].

EXAMPLES:

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

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

REFERENCE: REQ-5.1.5.3-03

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

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 TSP has a certificate generation service.

APPLICABILITY: Where the PKI has a certificate generation service.

REFERENCE: REQ-5.1.5.3-04

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

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;

c) the identifier of the certificate issuer;

RATIONALE:

NOTE:

EXAMPLES:

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

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

REFERENCE: REQ-5.1.5.3-05

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

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

a) keyUsage;

b) basicConstraints;

c) certificatePolicies.

RATIONALE:

NOTE:

EXAMPLES:

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

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

REFERENCE: REQ-5.1.5.3-06

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

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

a) keyUsage;

b) basicConstraints;

c) certificatePolicies.

RATIONALE:

NOTE:

EXAMPLES:

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

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

REFERENCE: REQ-5.1.5.3-07

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

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.

RATIONALE: The same public key may not be used for signature verification, and encryption or key agreement.

NOTE:

EXAMPLES:

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

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

REFERENCE: REQ-5.1.5.3-08

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

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 TSP and never left the certificate issuance service.

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

RATIONALE: A subject bringing forth his own public key should prove ownership of the public key.

The TSP 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 TSP itself needing public-key certificates.

The same private key should not be owned by distinct subjects, including other services of the TSP; if the private key was generated by the TSP but already provided to the subject once, the subject can and should prove its ownership.

The PKI 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 PKI itself needing public-key certificates.

The same private key should not be owned by distinct subjects, including other services of the PKI; if the private key was generated by the PKI but already provided to the subject once, the subject can and should prove its ownership.

NOTE:

EXAMPLES:

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

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

##5.4 Certificate status

RATIONALE:

NOTE:

EXAMPLES:

APPLICABILITY: Where the TSP has a certificate status service.

APPLICABILITY: Where the PKI has a certificate status service.

REFERENCE: REQ-5.1.5.4-02

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

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 TSP has a certificate status service, issuing CRLs.

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

REFERENCE: REQ-5.1.5.4-03

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

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

a) issuer;

b) issuerAltName;

c) nextUpdate.

RATIONALE:

NOTE: The issuerAltName may be absent from the profile if issued certificates do not use it.

EXAMPLES:

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

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

REFERENCE: REQ-5.1.5.4-04

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

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 TSP has a certificate status service, issuing OCSP responses.

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

REFERENCE: REQ-5.1.5.4-05

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

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

RATIONALE:

NOTE:

EXAMPLES:

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

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

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

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

EXAMPLES:

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

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

REFERENCE: 

## 6.1 Auditing

REFERENCE: ASS-REQ-5.1.5.1-01

OBJECTIVE: Verify that the TSP 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.

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:

Trigger an auditable event. Access the corresponding audit record. Verify the audit record contains at least:

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

REFERENCE: ASS-REQ-5.1.5.1-02

OBJECTIVE: Verify that the TSP 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 TSP determines its time stamps.

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.

Repeat the above several times from different accesses to the TSP in parallel and verify the produced time stamps from the TSP to be monotonic.

If the TSP may determine its time stamps by querying time information from a source it trusts, verify that it authenticates that source messages using state of the art mechanisms.

If the TSP may increment temporary or long-term time information stored locally, verify that the time information may not be used in data issued by the TSP until it has been properly been incremented, or alternatively that the service responsible for it cannot fail.

Repeat the above several times from different accesses to the PKI in parallel and verify the produced time stamps from the PKI to be monotonic.

If the PKI may determine its time stamps by querying time information from a source it trusts, verify that it authenticates that source messages using state of the art mechanisms.

If the PKI may increment temporary or long-term time information stored locally, verify that the time information may not be used in data issued by the PKI 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;

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

REFERENCE: ASS-REQ-5.1.5.1-03

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

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

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

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.

Verify the audit record contains the identity of the user that caused the event. Verify this identity to match that of the given user.

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

EVIDENCE:

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

REFERENCE: ASS-REQ-5.1.5.1-04

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

PREPARATION:  Ability to identify to the TSP 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 TSP as the given user. Trigger an auditable event as the given user. Access and copy audit records separately.

Attempt to perform all actions identified as possibly resulting in an audit record deletion; re-identifying to the TSP as necessary.

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.

Attempt to perform all actions identified as possibly resulting in an audit record deletion; re-identifying to the PKI as necessary.

Access audit records and verify they match the copy performed previously.

VERDICT: SUCCESS if the verification passes; else FAIL.

EVIDENCE:

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

REFERENCE: ASS-REQ-5.1.5.1-05

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

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.

Directly modify the contents of the stored audit record in the TSP.

Directly modify the contents of the stored audit record in the PKI.

Attempt to access the audit record.

VERDICT: SUCCESS if the last audit fails; else FAIL.

EVIDENCE:

a) the way the event was triggered, and the corresponding audit record which was copied;

b) the way the audit record was directly modified;

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

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

REFERENCE: ASS-REQ-5.1.5.1-06

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

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 TSP. Trigger auditable events until the audit log is full, or nearly so.

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

Verify that a given additional auditable event cannot be performed.

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

c) the way the additional event was attempted to be triggered, and the corresponding response from the PKI.

REFERENCE: ASS-REQ-5.1.5.1-07

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

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.

The list of auditable events may be reduced.

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 TSP;

c) the way the signatures, keyed hashes or authentication codes were verified, and the corresponding responses from the PKI;

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-5.1.5.1-08

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

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.

Wait sufficiently such that 2 audit log signing events occur.