1653680 - IdenTrust: OCSP Responder missing id-pkix-ocsp-nocheck

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[IdenTrust]

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

Steps to reproduce:

On July 14, 2020 we received an email message via our certificate problem report public address ([e-mail]) making us aware of a missing id-pkix-ocsp-nocheck extension in the delegated OCSP signing certificate 'IdenTrust Commercial Root CA 1 OCSP Signer'
We have resolved the issue on the same day and will provide a formal Incident report no later than July 24, 2020

Comment 1

[IdenTrust]

We are delayed in completing the Incident Report. We expect to complete it by Tuesday July 28.

Comment 2

[IdenTrust]

Attachment: IdenTrust OCSP Responder Missing id-pkix-ocsp-nocheck.txt

Comment 3

[IdenTrust]

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.
   IdenTrust:
   On July 14, 2020 we received an email message via our certificate problem report public address ([e-mail]) making us aware of a missing id-pkix-ocsp-nocheck extension in the delegated OCSP signing certificate 'IdenTrust Commercial Root CA 1 OCSP Signer'

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.
   IdenTrust:
   2020-07-14 12:36 MT: Received email notification reporting the issue
   2020-07-14 13:20 MT: Acknowledged issue and started to investigate.
   2020-07-14 16:00 MT: Confirmed non-compliance with Baseline Requirements (BR) 4.9.9 (2) and discovered that an update to the OCSP responders on 6/23/2020 caused the discrepancy with the BR.
   2020-07-14 17:00 MT: Placed back the previously BR compliant delegated OCSP signing certificate.

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.
   IdenTrust:
   Yes, the BR compliant delegated OCSP signing certificate was placed back on the same day the noncompliant version was reported.

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.
   IdenTrust:
   One delegated OCSP signing certificate with validity period from 6/24/2020 until 7/24/2020

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.
   IdenTrust:
   See attachment

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
   IdenTrust:
   Near the end of 2019, IdenTrust pre-issued all OCSP Responder certificates for use in 2020, with validity periods established for each month the certificates were planned to be released. At that time all certificates held the no-check extension in compliance with BR 4.9.9 (2).

As part of our response to May 2020 CA communications survey, IdenTrust reexamined implementation of OCSP Responders and as a result of internal mis-communication between operations staff and BR SME, the No-Check extension was removed from the OCSP signing certificate identified in #5.

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.
   IdenTrust:
   IdenTrust normal process is to generate the OCSP Response signing certificates once per year, and deploy certificates on a monthly basis. For this scenario, the particular process that was utilized was designed to allow the Operations team to move quickly in situations where an operational OCSP Response certificate requires expedited updates (“Expedited Update Process” or “EUP”). The current Expedited Update Process does not have a BR SME review. To reduce the likelihood of repeating such non-compliance in the future, the Expedited Update Process has been modified, adding an additional BR SME review step to confirm the change will not result in non-compliance with BR(s). This step is to be completed prior to approval of the request to deploy a new OCSP Response signing certificate.

Comment 4

[Ryan Sleevi]

Near the end of 2019, IdenTrust pre-issued all OCSP Responder certificates for use in 2020, with validity periods established for each month the certificates were planned to be released.

Could you share more about this process, including the key management process for these responder certificates? One of the things called out in https://tools.ietf.org/html/rfc6960#section-4.2.2.2.1 is recognizing that a compromise of the responder's key is as serious as a compromise of the CA key used to sign CRLs. Pregenerating certificates in this fashion seems to create a risk that, if an adversary were to compromise and or/obtain one responder key, they might also be able to obtain forward-dated certificates and keys, defeating the very purpose of using short-lived responders.

Sharing more about the responder lifecycle, from creation through expiration, seems useful, including any discussion of EUP, as appropriate.

Comment 5

[IdenTrust]

At a high level, we follow this process:

• Under m of n control, scripted and videotaped ceremonies are conducted for OCSP Signing Key generation (on FIPS Compliant HSMs) and issuance of OCSP Signing Certificates. These take place within our data center and are restricted to eligible persons from a pre-designated and authorized trusted employees.
• Upon completion of the ceremony, pre-generated OCSP Signing Certificates are stored within a dual-control located within our secured data center.
• Complete chain of custody is maintained for all pre-generated OCSP Signing Certificates from generation to date of first use in a publicly available OCSP Responder.
• Access to pre-generated OCSP Signing Certificate prior to and at the time of production installation requires m of n access control with m being minimum of 2 and eligible persons are from a pre-designated and authorized trusted employees.
• All OCSP Signing Keys are generated and stored within FIPS 140-2 Level 3 compliant HSMs
• Access to HSM requires m of n access control with m being minimum of 2 and eligible persons from a pre-designated and authorized trusted employees.
• Datacenter access require dual person control and requires persons from a pre-designated and authorized trusted employees list.
• At a designated date (minimum of once per month), relevant pre-generated OCSP Signing Certificate is retrieved and installed onto the appropriate OCSP Responder\Signer.

The EUP process is as described above except that the new OCSP Signing Certificate is issued at the same time of deployment into production.

Comment 6

[Ryan Sleevi]

Thanks. I think those details in Comment #5 are very helpful. I'm still have some degree of unease if the (OCSP signing) keys used to revoke certificates that had their (CA) keys compromised were stored on the same HSM, but I suppose in that (hopefully unlikely) scenario the step would just be to revoke the root certificate.

Comment 7

[Ben Wilson]

I intend to close this bug on 14-Sept-2020 unless there are additional questions or concerns.