Atos: Incorrect OCSP Delegated Responder Certificate
Categories
(CA Program :: CA Certificate Compliance, task)
Tracking
(Not tracked)
People
(Reporter: ryan.sleevi, Assigned: u636358)
Details
(Whiteboard: [ca-compliance] [ocsp-failure])
The following was originally reported to m.d.s.p. at https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg13493.html
ATOS has issued one or more OCSP Delegated Responders, as defined within RFC 6960, Section 2.6 and Section 4.2.2.2, without including the id-pkix-ocsp-nocheck
response, as required by the Baseline Requirements, Version 1, Section 13.2.5 through Version 1.7.0, Section 4.9.9
Example certificate: https://crt.sh/?id=2595911605
Please provide an incident report, including the timeline for revocation.
We started to investigate this issue. More Information will follow.
Yesterday we revoked 2 of 4 affected CAs and the remaining CAs will be revoked today. So all affected CAs will be revoked within 7 days. The detailed incident report will follow end of this week.
- 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.
Atos got aware about this topic by following m.d.s.p post entitled “SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert”. Additionally an e-mail from Bugzilla was received, after this bug had be opened.
- 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.
02-July-2020 03:49: e-mail form Bugzilla
02-July-2020 09:00 Reading and evaluating the post on m.d.s.p. “https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/EzjIkNGfVEE”
03-July-2020 10:00 Informing Customers about upcoming revoking and replacement of the ICAs.
07-July-2020 8:19 Issuance of the first replacement CA without id-kp-OCSPSigning EKU
07-July-2020 8:33 Revocation of 2 ICA
08-July-2020 11:13 Issuance of the next 2 replacement CA without id-kp-OCSPSigning EKU
08-July-2020 11:28 Revocation of 2 ICA
14-July-2020 09:00 Appointment with auditor for review of key destruction.
- Whether your CA has stopped, or has not yet stopped, certificate issuance or the process giving rise to the problem or incident. A statement that you have stopped will be considered a pledge to the community; a statement that you have not stopped requires an explanation.
The affected ICA certificates have been issued at 2019-06-20, 2019-10-30, 2020-01-31, 2020-03-17. After 2020-03-17 no further ICA using the id-kp-OCSPSigning EKU have been issued.
All affected ICA have been revoked at 2020-07-07 and 2020-07-08.
- In a case involving certificates, a summary of the problematic certificates. For each problem: the number of certificates, and the date the first and last certificates with that problem were issued. In other incidents that do not involve enumerating the affected certificates (e.g. OCSP failures, audit findings, delayed responses, etc.), please provide other similar statistics, aggregates, and a summary for each type of problem identified. This will help us measure the severity of each problem.
The following ICA certificates are involved:
https://crt.sh/?id=2070270509
https://crt.sh/?id=1618718808
https://crt.sh/?id=2595911605
https://crt.sh/?id=2411246003
These certificates where issued on 2019-06-20, 2019-10-30, 2020-01-31 and 2020-03-17 and where used for S/MIME and Client-Auth Certificates. All four certificates contain an id-kp-OCSPSigning EKU without id-pkix-ocsp-nocheck
- In a case involving certificates, 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. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any.
See #4
- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
A misinterpretation of the sentence (“For a Subordinate CA Certificate to be considered Technically Constrained, the certificate MUST include an Extended Key Usage (EKU) extension specifying all extended key usages that the Subordinate CA Certificate is authorized to issue certificates for.“) of the of Baseline Requirements was made. We assumed this EKU was needed, because the ICAs issues OCSP signer certificates, which includes the id-kp-OCSPSigning EKU. The use case of OCSP delegation was never considered by including the EKU and the Atos environment was never configured to act for this case.
- List of steps your CA is taking to resolve the situation and ensure that such situation or incident will not be repeated in the future, accompanied with a binding timeline of when your CA expects to accomplish each of these remediation steps.
We revoked all affected ICAs within seven days, as defined under the Baseline Requirements Section 4.9.1.2. For future issuance, all ICA Profile have been updated and the id-kp-OCSPSigning EKU has been removed. The checklist for ICA creation got an extra checkpoint the check to prevent, that id-kp-OCSPSigning EKU is set for ICA. An example for a replacement CA without id-kp-OCSPSigning EKU is https://crt.sh/?id=3054024520
The private key of the ICA will be destroyed on 2020-07-14 together with our auditors.
Comment 4•4 years ago
|
||
Thanks. Please provide an update here when that destruction has been completed.
Yesterday (2020-07-14) the private keys of the of the affected ICAs have been destroyed in the presence of our auditor. All affected ICA have been revoked and the private keys have been destroyed.
Comment 6•4 years ago
|
||
I believe that this bug can be closed. I'll queue this to be closed on or after 24-July-2020 unless we receive additional questions or issues to resolve.
Updated•4 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Description
•