1671037 - SecureTrust: CPS section 6.1.1.1 number 3 non-compliance event

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Andrea Holland]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:80.0) Gecko/20100101 Firefox/80.0

Comment 1

[Andrea Holland]

SecureTrust became aware of a CPS non-compliance event of section 6.1.1.1 number 3 on 10.01.2020 regarding a video recording of a key generation ceremony on 09.21.2020. We are generating a formal incident report which we will be posting when complete.

Comment 2

[Andrea Holland]

1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

We became aware of an issue regarding an intermediate key generation videotape from our 09.21.2020 CA room entry for generation of SecureTrust controlled email and client authentication intermediates when a request was made to have that video retrieved and moved to long-term storage.  In our CPS section 6.1.1.1 number 3, we have documented that Certificate Authority key generation ceremonies will be: 
3.  Performed in accordance with a documented key generation ceremony that is either audited by the current WebTrust auditor or videotaped. Following completion of the ceremony, all Trustwave employees present shall attest in signatory form to the adherence of the procedure. These records shall be kept for a period of at least 7years after the end of the Validity Period for the generated Key Pair;

2. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done

• 09.21.2020, 09:00 AM CDT CA room entry was performed in order to generate new SecureTrust controlled email and client authentication intermediates with all the controls in place from our CPS section 6.1.1.1 number 3
• 09.28.2020, 09:11 AM CDT Request was made to IT for a copy of the video recording.
• 10.01.2020, 10:14 AM CDT Response from IT regarding the request that due to a hardware failure, this video was unable to be retrieved and placed into long term storage.

3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

No end-entity certificates have been or ever will be issued from these SecureTrust controlled email and client authentication Intermediate CAs.  The Intermediate CA certificates were revoked on 10.08.2020.

4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.

The following intermediate certificates were issued on 09.21.2020 during the CPS non-compliance event
http://crt.sh/?id=3448533127
http://crt.sh/?id=3448533132
http://crt.sh/?id=3448533131
http://crt.sh/?id=3427370833
http://crt.sh/?id=3439320286
http://crt.sh/?id=3439350541
http://crt.sh/?id=3427339529

5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

http://crt.sh/?id=3448533127
http://crt.sh/?id=3448533132
http://crt.sh/?id=3448533131
http://crt.sh/?id=3427370833
http://crt.sh/?id=3439320286
http://crt.sh/?id=3439350541
http://crt.sh/?id=3427339529

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

A failure in hardware caused the video recording of this event to be destroyed prior to being stored in long-term audit storage.

7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

We are currently examining ways to provide more redundancy to the design going forward. Specifically, increasing our hardware to ensure that we have redundancy in both the video recording and short-term storage of videos from key generation events. In the near term we are recording the key generation ceremonies with multiple devices. We will be updating this bug with the long-term plan when it is completed.

Comment 3

[Andrea Holland]

During our next CA room entry, we will install an additional permanent video camera to operate as a backup recording device. In order to provide full redundancy, the camera’s short-term storage will be separate from the existing cameras’ short-term storage.

Comment 4

[Andrea Holland]

The additional camera has been installed as a backup recording device. That completes our planned remediation; if there are no other comments please close out this bug.

Comment 5

[Ben Wilson]

I'll close this on Friday 12-Feb-2021 unless there are other reasons to keep it open.