CWA 14167-3

[1] In compliance with CWA 14167-1, Section 5.2.3.2 CG1.1-3, the Digi-CA™ ensures the integrity, data origin authenticity, and where necessary, the privacy and confidentiality of the Digi-ID™ [2] request message and the Digi-ID™ request is processed securely and checked for conformance with the applicable Certificate Policy. Before the Digi-ID™ generation, the Digi-CA™ [3] ensures Proof of Possession is validated.

In compliance [4] with CWA 14167-1, Section 5.2.3.2 CG1.4-6, the key used to sign a QC is only used for signing QCs and, optionally, the related Revocation Status Data and this service only generate Digi-IDs™ that are consistent with the allowed profiles as determined by the Security Officer. All Digi-IDs™ have the following properties:

In compliance with CWA 14167-1, Section 5.2.3.2 CG2.1-2, for re-certification [4], the Digi-CA™ ensures process security against Digi-ID™ substitution attacks and the re-certification of Control and Infrastructure Digi-IDs™ with 5.1.5.2 KM.4 - Key Change.

In compliance with CWA 14167-1, Section 5.2.3.2 CG2.3, the Digi-CA™ ensures that all the Signing Keys are updated prior to their expiry. The related (renewed) Public Keys provide at least the same level of trust as when they were initially distributed. This is accomplished by providing at least the following intermediary certificates to prove possession of the new Private Key as follows:

2. Providing a Digi-ID™ of the new Public Key signed with the old Private Key

3. Providing the new self signed Digi-ID™ (signed with the new Private Key)

In compliance with CWA 14167-1, Section 5.2.3.2 CG2.4, the Digi-CA™ re-certifying and/or re-keying of Subject keys, is as secure as the initial certificate generation and the Subject Certificates are renewed prior to their expiry. The Digi-CA™ automatically rejects a renewal request signed with an expired or revoked key.

In compliance with CWA 14167-1, Section 5.2.3.2 CG4.1, the Digi-CA™ logs the following events:

In compliance with CWA 14167-1, Section 5.2.4.1 D1.1-2, the Digi-ID™ dissemination by the Digi-CA™ is limited to the Subject, and to Relying Parties according to the limits expressed by the Subject and the dissemination process manages the Digi-IDs™ accordingly.

In compliance with CWA 14167-1, Section 5.2.4.1 D2.1, if a repository is set up, an access control policy is defined to securely manage the access to stored data and read access privileges are granted to Subjects and to authorised entities according to the rules defined by the Subject and the Security Policy whilst write access privileges are limited to authorised roles, according to the definition of roles proposed in 5.1.1.

In compliance with CWA 14167-1, Section 5.2.5.2 RM1.1-6 and RM 2.1, requests and reports relating to revocation and/or suspension are processed by the Digi-CA™ in a timely manner and the maximum delay between receipt of a revocation and/or suspension request and the change to Digi-ID™ status information does not exceed 24 hours.

All requests for suspension, reinstating and revocation is authenticated and validated and once a Digi-ID™ is definitely revoked the Digi-CA™ ensures that it cannot be reinstated. Revocation of certificates related to all Signing Keys is only possible under at least dual control and status changes can be instigated by authenticated:

The Certificate Status database is updated immediately after request/report processing is complete. The Digi-CA™ is able to revoke any Digi-ID™ it has issued, even after a disaster.

In compliance with CWA 14167-1, Section 5.2.5.2 RM2.2, where Periodical Messaging is used, the Digi-CA™ supports the following requirements:

For an offline status repository (e.g. CRL accessible through directories) the Revocation Status Service is updated at least on a daily basis
For an online status repository (e.g. OCSP [5] responder) the Revocation Status Service is updated when a status change occurs and additionally at least on a daily basis
Each update message includes the name and digital signature [6] of the message issuer, and the time of status change
The messages only indicates the Digi-IDs™ that are revoked/suspended
For each Digi-ID™ in the list, its serial number and a reason for the status change is provided in the message

In compliance with CWA 14167-1, Section 5.2.5.2 RM2.3 and RM3.1, where Real-Time Messaging is used, the Digi-CA™ meets the following requirements:

Where the Revocation Status Service queries a certificate status, the Certificate Status database MUST reply by providing the current status of that certificate
A trusted channel (Fig1: Message B) MUST exist between the Revocation Management Service and the Revocation Status Service
This trusted channel MUST be configured to minimise denial of service attacks on the messaging
Request and response messages MUST be protected from replay attacks (e.g. by using nonces).

And all events related to certificate status change requests, whether approved or disapproved, are logged.
In compliance with CWA 14167-1, Section 5.2.6.2 RS1.1-3, Real-time or Periodic Messages provided to this service are only from trusted Revocation Management Services and if the Digi-CA™ is providing an ‘online’ revocation status service, it validates the integrity and authenticity of Real-time or Periodic messages sent to it and it ensures that replies to responses from the Certificate Status database are for the requested certificates.

In compliance with CWA 14167-1, Section 5.2.6.2 RS2.1-4 and 3.1, all certificate status responses from the ‘online’ Revocation Status Service are digitally signed by the Revocation Status Service using its infrastructure keys and signature algorithms/keys used for status response are compliant with [ALGO]. The response message contains the time at which the Revocation Status Service/Issuer signed the response. All ‘online’ Revocation Status Service certificate status requests and responses are logged.

In compliance with CWA 14167-1, Section 5.3.1.2 TS1.1-2, the Digi-CA™ controls the origin of each request before checking its correctness and verifies that the request for time stamping uses a hash algorithm that is specified as approved by [ALGO].

In compliance with CWA 14167-1, Section 5.3.1.2 TS2.1-2, the Digi-CA’s™ trusted time source(s) are synchronised to Co-ordinated Universal Time (UTC) within the tolerance dictated by Certificate Policy e.g. to within 1 second and this is the same source as specified in requirement SO3 and the Digi-CA™ clock is synchronised with the UTC using a mechanism that is demonstrated to be reliable.

In compliance with CWA 14167-1, Section 5.3.1.2 TS3.1-3, the Serial Number used within the time stamping token is unique for each token issued by Digi-Sign and this property is preserved even after a possible interruption of the service. As well as Time Parameter inclusion, the time stamping token includes the accuracy of the time source used if this is exceeds that required by the time stamping policy. An indication of the policy under which the time stamping token was created is included.

In compliance with CWA 14167-1, Section 5.3.1.2 TS4.1-6, the Time Stamping Authority [TSA] Signing Keys are generated and stored in a secure cryptographic module and the cryptographic module of fulfils the requirements of KM 1.2. The TSA Control Keys are stored in a hardware cryptographic device (HCD) and the TSA Signing Key is only used for signing time stamping tokens produced by the TSA. The TSA ensures that the time stamping token’s response contains the same datum that was sent with the request and that the signature algorithms/keys used by the TSA meets the cryptographic requirements specified in [ALGO].

In compliance with CWA 14167-1, Section 5.3.2.2 TS5 and 6, the following Time-Stamping [7] Service specific events are logged:

And all Time-Stamp Tokens are archived in accordance with [AR 1.1].

In compliance with CWA 14167-1, Section 5.3.1.2 SP1-4, the Eracom and nCipher HSMs meet this criteria as certified in their FIPS accreditation and as the key pairs are generated within these certified HSMs this satisfies the requirement.