Closed Bug 1649944 Opened 4 years ago Closed 4 years ago

Camerfirma: Incorrect OCSP Delegated Responder Certificate

Categories

(CA Program :: CA Certificate Compliance, task)

Product:
CA Program
Component:
CA Certificate Compliance
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: ryan.sleevi, Assigned: eusebio.herrera)

Details

(Whiteboard: [ca-compliance] [ca-misissuance])

The following was originally reported to m.d.s.p. at https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg13493.html

Camerfirma 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=12729554

Please provide an incident report, including the timeline for revocation.

We confirm the receipt of the information and we start to investigate it.

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 were aware of the problem when Ryan Sleevi opened this bug and the mdsp threat “SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert ” (https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg13493.html) was created.

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.

2.1 July 2nd 2020, Camerfirma started the study of the case and its impact in order to detect all the affected CAs.

2.2 July 6th 2020, Camerfirma contacted the affected CA to inform them about the situation and establish a remediation plan for the situation together.

2.3 July 8th 2020, Camerfirma include the needed information in the incident report.

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

We detected three affected CAs:

a) The CA OMC has not stopped issuing certificates yet.

The platform to issue certificates for this CA, hosted and managed by Camerfirma can only use its key to issue certificates or CRLs.
It is technically impossible to generate OCSP responses from this platform.
This platform for the certificate issuing and the platform that signs OCSP responses are entirely independent. The platform that issues OCSP responses does not have any kind of access to this CA key.

b) There are two other CAs detected with that problem:

  • AC CITISEG II - 2015
  • Entitat de Certificació de l'Administració Pública Andorrana

They have stopped issuing certificates. They are already revoked but their keys still exist.

4.- 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 certificate detected from the beginning was the following:

We detected other two affected certificates that had been revoked and whose keys have not been destroyed yet.

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

https://crt.sh/?id=12729554
https://crt.sh/?id=57898640
https://crt.sh/?id=49167479

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

The mistake was made because a misinterpretation when we did not detect that the inclusion of the EKU OCSP Signing without the noCheck extension generates a conflict with the RFC6960. This misinterpretation has been clarified thanks to the mdsp threat -> SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert.

The affected certificate (OMC) https://crt.sh/?id=12729554 will be revoked and its keys destroyed within a deadline agreed with the client (within the next 9 months).

The situation for this CA is critical now because it belongs to ORGANIZACION MEDICA COLEGIAL (COLLEGE MEDICAL ORGANIZATION and their certificates are necessary to sign all the medical prescriptions by the doctors and if we revoked the CA and their service stopped it would have an enormous impact for the Health System in Spain.

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

7.1 Establish a control to avoid the issuance of CA certificates with this EKU (already done)

7.2 Destroy the keys for the CAs AC CITISEG II – 2015 and Entitat de Certificació de l'Administració Pública Andorrana (by July 15h )

7.3 Application for inclusion the CA OMC to OneCRL (by July 15th)

7.4 Incorporate additional controls during the HSM log checking to detect any activity related to the OCSP responder (under study to determine the deadline)

7.5 Stop issuing certificates with the CA OMC (within the next 9 months)

7.6 Destroy the private key for the CA OMC (within the next 9 months)

(In reply to Eusebio Herrera from comment #2)

6.- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
The affected certificate (OMC) https://crt.sh/?id=12729554 will be revoked and its keys destroyed within a deadline agreed with the client (within the next 9 months).

9 months seems like an extraordinarily long time. If certificate lifetimes were only a year, it would seem to have the effect of nearly doing nothing at all before they expired.

How was this date determined? Why is this date reasonable, as opposed to 1 month? There's not enough details in this report to provide understanding and insight here into the thought process. How does this fit with https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation and understanding how you're evaluating the risk factors?

The situation for this CA is critical now because it belongs to ORGANIZACION MEDICA COLEGIAL (COLLEGE MEDICAL ORGANIZATION and their certificates are necessary to sign all the medical prescriptions by the doctors and if we revoked the CA and their service stopped it would have an enormous impact for the Health System in Spain.

Nothing about the proposed remediation seems to offer any insight into "the factors that prevented timely revocation of the certificates, and include a set of remediation actions in the final incident report that aim to prevent future revocation delays.". Absent a clear plan like this to prevent future delays, and a clear plan to establish how nothing could go wrong, has go wrong, or will go wrong, any delay should be seen as unacceptable. This is the opportunity for the CA to comprehensively demonstrate the steps they're taking. For example, your 7.4 has no timeline attached to it, among other things.

Flags: needinfo?(eusebio.herrera)

Please, find below some extra information about the questions that you raised.

First of all, the reason why we have indicated that we plan to revoke this intermediate CA in 9 months. This is because this intermediate CA is in end-of-life. This intermediate CA will be revoked immediately once the new CA which are going to take over it, were approved by the Spanish supervisory body, a process that may take between six and nine months.

We have already talked with our client (CGCOM) and our national supervisor body to share this issue and try to minimize this time considering this special situation. We all are aware that this vulnerability and we have already sent the CAR to the National Supervisor, including also a migration plan to put in place as soon as we have the approval. We do not think this is going to take us more than 6 working months (considering that August is a holiday period for the National Supervisor in Spain).

As we indicated before, we are going to establish the additional controls that prevent this attack to take place.

Additionally to the controls we already deployed to avoid the intermediate CA key compromise (necessary to exploit this vulnerability) we will analyze the traffic between our PKI CA module and the HSMs where the intermediate CA private keys are stored. No OCSP traffic should be detected since our OCSP services are in a different and detached network area.

We also will make aware third-party applications that the combination of KU and AKI can help to detect fake OCSP responses to minimize the impact.

These controls, detailed in the bug, will be communicated to the auditor and national supervisor body. The information about this situation will be included in the next audit report.

Considering the previous information, we have been analyzing the risk vs. the impact of this decision and we consider that the remaining risk that we have applying the controls is much less than the risk that existed before this situation.

Flags: needinfo?(eusebio.herrera)

As indicated in point 7.2 above, today we have proceeded to destroy the keys of the CAs:

  • AC CITISEG II – 2015
  • Entitat de Certificació de l'Administració Pública Andorrana.

An update is needed in this bug or in Bug 1652603.

Regarding the point 7.3, we have already asked for the inclusion of the CA OMC in OneCRL and we are waiting for the confirmation and regarding the point 7.4 we have talked to our providers and we are studying the possibilities together.
We will update the information as soon as we have more details.

We have already received response about the inclusion of the CA in oneCRL and they have indicated that it has no impact because it is a CA that cannot be used for TLS based on its EKU. So, finally, this CA won't be added to oneCRL.

Subject: CN=OMC; OU=ENTIDAD DE CERTIFICACION; O=ORGANIZACION MEDICA COLEGIAL; C=ESIssuer: CN=AC Camerfirma - 2009; O=AC Camerfirma S.A.; C=ES
Certificate Serial Number: 06B8680BCF7B4E7E
SHA-1 Fingerprint: A218EFEDDEABDC0B30DB08F693B78A46A68AFC9B
SHA-256 Fingerprint: C17611DB7B311361E20D7B8231AADF478BCB7FFA0BE585C06DE2309223C2EF8A
Key Usage: Certificate Sign, CRL Sign
Extended Key Usage: ExtKeyUsageClientAuth,ExtKeyUsageEmailProtection,ExtKeyUsageOCSPSigning

I've updated the info about the revocation of this CA in https://bugzilla.mozilla.org/show_bug.cgi?id=1652603

I am willing to close this bug and consolidate further discussion under Camerfirma's bug for delayed revocation, Bug #1652603. The comments in this bug contain many valuable disclosures and observations which are preserved for cross-reference in that bug. However, before I close this bug, I would like to understand what steps Camerfirma takes to ensure it is following and participating in discussions that highlight these types of issues. For instance, I assume that Camerfirma follows and occasionally participates in discussions about the CA incidents of other CAs in Bugzilla; changes and discussions of CA/Browser Forum Guidelines, and in particular, certificate profiles; and m.d.s.p posts, which discuss developments and interpretations of the applicable standards for CAs. (Section 2.1 of the Mozilla Root Store Policy states, "CAs MUST follow and be aware of discussions in the mozilla.dev.security.policy forum, where Mozilla's root program is coordinated. They are encouraged, but not required, to contribute to those discussions.") I think that understanding steps you take to ensure this expectation is met, in order to detect and prevent future issues, is useful to ensure that no future interpretation issues arise.

Camerfirma takes the following steps to ensure that we are aware of all the new information:

  • We follow the discussions in mozilla.dev.security.policy forum
  • We participate in Bugzilla Camerfirma's cases and follows relevant cases for potential improvement.
  • We participate in all the surveys requested in CCADB's CA Communications (Page) as is required by Mozilla Root Store Policy [4.2 Surveys].

Closing this bug. Please refer to Bug #1652603 for further proceedings.

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Product: NSS → CA Program
Whiteboard: [ca-compliance] → [ca-compliance] [ca-misissuance]
You need to log in before you can comment on or make changes to this bug.