Closed Bug 1649943 Opened 5 years ago Closed 5 years ago

Firmaprofesional: 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: chemalogo)

Details

(Whiteboard: [ca-compliance] [ocsp-failure])

Attachments

(1 file)

new_ICAs_wo_EKU_OCSPSigning.zip
5.98 KB, application/x-zip-compressed
Details

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

Firmaprofesional 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=240192053

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

First of all thanks a lot for reporting the finding.

We will look into it ASAP. At a quick glance we can say the following: the example that you provide is not intended to be an OCSP Responder but a technically constrained CA certificate pursuant this definition "For a 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 is authorized to issue certificates for. The anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this extension. "

Sorry. You've already answered with your example: "For example, consider a certificate like https://crt.sh/?id=2657658699 . This certificate, from HARICA, meets Mozilla's definition of "Technically Constrained" for TLS, in that it lacks the id-kp-serverAuth EKU. However, because it includes the OCSP Signing EKU, this certificate can be used to sign arbitrary OCSP messages for HARICA's Root!"

All Firmaprofesional Intermediate CAs are operated by Firmaprofesional. This is publicly stated in our CPS (https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_CPS-200417-ES-sFP.pdf) since 2015, section 1.3.2. Certification Authority (CA): "[...] The subordinate CA’s can be issued in Firmaprofesional’s name or in the name of another TSP. In either case all CAs within the Firmaprofesional Certification Hierarchy must be operated technically by Firmaprofesional, within the infrastructure of Firmaprofesional.", thus, in our opinion, minimizing the biggest theoretical risk.

As others, we considered that, to properly technically constrain an ICA implied the need of considering all the types of leaf certificates issued by that ICA, and therefore this would require including the OCSP Signing EKU, without implying that the CA is acting as a delegated responder, which is clear according to RFC6960 but not that clear according to the BR.

We are closely following the m.d.s.p. thread "SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert" to get a better understanding, while weighting up different approaches and their impact to address the issue.

Incident Report:

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 thanks to the mdsp threat entitled 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), 2nd of July 8:00 AM - CEST.

Ryan Sleevi also created a Bugzilla ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1649943

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

2nd of July: we carefully reviewed the thread trying to understand the security issue.

2nd of July: we identified that the main security issue does not affect us, since we manage all the keys involved: "[...] The subordinate CA’s can be issued in Firmaprofesional’s name or in the name of another TSP. In either case all CAs within the Firmaprofesional Certification Hierarchy must be operated technically by Firmaprofesional, within the infrastructure of Firmaprofesional." .

3rd of July: we made this public, in the ticket aforementioned (): "[...] The subordinate CA’s can be issued in Firmaprofesional’s name or in the name of another TSP. In either case all CAs within the Firmaprofesional Certification Hierarchy must be operated technically by Firmaprofesional, within the infrastructure of Firmaprofesional." CPS (https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_CPS-200417-ES-sFP.pdf) since 2015, section 1.3.2. Certification Authority (CA).

3rd of July:

  • pursuing some of the approaches identified in the mdsp we began to collect evidence of the fact that we have total control over the keys and that the theoretical threat has not materialized. Key Ceremonies Minutes, Security World (nCipher) stored keys, CA log on OCSP configuration and so on.
  • (and still doing):
    • Identifying different approaches and assessing their impact the Community and on our clients
    • following mdsp to get a better understanding of the how the issue occured, and also different approaches from different experts and other CAs

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.

Our CA has not stopped the issuance of the certificates.

All CAs are under the control of Firmaprofesional and it is not possible for any third party other than Firmaprofesional to create fraudulent OCSP responses, so that we consider that there is not any additional security risk related to this issue.

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

Four certificates are affected:

  1. https://crt.sh/?q=240192053: “SIGNE Autoridad de Certificacion”
  2. https://crt.sh/?q=10601239: “AC Firmaprofesional - INFRAESTRUCTURA”
  3. https://crt.sh/?q=536779027: “AC Firmaprofesional - CFEA”
  4. https://crt.sh/?q=536779028: “AC Firmaprofesional - OTC”

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.

Four certificates are affected:

  1. https://crt.sh/?q=240192053: “SIGNE Autoridad de Certificacion”
  2. https://crt.sh/?q=10601239: “AC Firmaprofesional - INFRAESTRUCTURA”
  3. https://crt.sh/?q=536779027: “AC Firmaprofesional - CFEA”
  4. https://crt.sh/?q=536779028: “AC Firmaprofesional - OTC”

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

The mistakes were made due to a generalized misinterpretation of how a CA certificate should be technically constrained.

Several CAs have made the same mistake due to the fact that we interpreted how to technically constrain a CA as a kind of enforceable standard superseding RFC6960 in case of conflict.

During the discussion on mdsp it has been clarified that we misinterpreted the scope and the enforceability of the meaning of adding EKUs to an Intermediate CA (ICA) in order to technically constrain it.

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

Collect evidence that demonstrates that only Firmaprofesional is in control of the affected keys and that they have not been used for OCSigning. These evidence include:

  • Key Ceremony Minutes signed by a notary including information of the Security World used to protect the keys
  • Review of the configuration log in EJBCA on which certificates have been enabled as OCSP Responder.
  • EJBCA VA test on pre production environment, the ICA certificates can not be configured as OCSP Responders.

9th of July:

  • reissuance of all four ICAs without the offending EKU, using the same key pair
  • Update CCADB, Spanish Government, other certificate validators, relying parties and CPS
  • Asking to add to OneCRL the following certificates:

Before 8th of August. Revocation of:

As soon as the new certificates appear on the Spanish Trust Services List (https://sede.serviciosmin.gob.es/Prestadores/TSL/TSL.xml). Revocation of:

(In reply to chemalogo from comment #4)

2nd of July: we identified that the main security issue does not affect us, since we manage all the keys involved: "[...] The subordinate CA’s can be issued in Firmaprofesional’s name or in the name of another TSP. In either case all CAs within the Firmaprofesional Certification Hierarchy must be operated technically by Firmaprofesional, within the infrastructure of Firmaprofesional." .

As mentioned on m.d.s.p., this still affects you, even though you're claiming 1P control.

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

Collect evidence that demonstrates that only Firmaprofesional is in control of the affected keys and that they have not been used for OCSigning. These evidence include:

  • Key Ceremony Minutes signed by a notary including information of the Security World used to protect the keys
  • Review of the configuration log in EJBCA on which certificates have been enabled as OCSP Responder.
  • EJBCA VA test on pre production environment, the ICA certificates can not be configured as OCSP Responders.

This seems incomplete. Did you perhaps submit this too soon?

While configuration is, no doubt, an important part of demonstrating that these cannot be misused, I'm loathe to believe it's an appropriate control, for the same reason we can't say configuration prevents misissuance. If Firmaprofesional is wrong in its analysis, or to be more precise, if it's overly optimistic (e.g. as directed above, by not understanding the security issue), then it seems a control that relies on "We didn't configure it that way" does nothing to provide assurance to anyone that it can't, hasn't, and won't be.

I don't see anything in this plan that proposes how to address that. Is there something missing?

9th of July:

  • reissuance of all four ICAs without the offending EKU, using the same key pair

Reminder: This does nothing to mitigate the issue. At best, this is temporary, until the key is rotated and destroyed.

What do you propose for non-OneCRL clients? Or is the solution to remove the root for those clients?

Before 8th of August. Revocation of:

Because you're re-rolling certificates with the keys, this, as mentioned, does nothing to mitigate the underlying issue.

When will you be re-rolling keys, when will you be providing evidence of key destruction, and what will you be doing until then to prove they haven't, can't, and won't be misused, in a transparent and reliable way? As Firmaprofesional relies on ETSI audits, there's serious concerns about the suitability about using such audits, given the lack of transparency and accountability with respect to such reporting.

Flags: needinfo?(chemalogo)

In light of the different conversations and conclusions in m.d.s.p., contrasting opinions with other experts and making deeper analysis of internal and external impact, Firmaprofesional's position is as follows:

  • We appreciate the overall improvement that security has had in terms of Web PKI in recent years, thanks to the collaboration of watchmen who have identified potential risks and proposed mitigation measures that have allowed those risks to not materialize.

  • The certificates affected by the case "SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert" should not represent a risk, if all the players adhered to the standards that regulate them. However, it is clear that the different standards are not necessarily perfect, there is room for interpretation, and global security depends not only on how a subset of the actors interpret the standards, but on how the globality of the agents involved interpret them. In these circumstances, the aforementioned certificates could represent a potential risk, which can be partially mitigated according to the circumstances of each player.

  • For this reason, and despite the fact that Firmaprofesional has exclusive control of the private keys of all the CAs that are part of its hierarchy and thus declares it in its CPS, and that none of the ICA certificates affected have the keyUsage digitalSignature, we understand that the destruction of keys can help to improve the global perception of security and we will propose a new plan no later than Wednesday, July 22, 2020, including key destruction.

Flags: needinfo?(chemalogo)
Whiteboard: [ca-compliance] → [ca-compliance] Next update 22-July-2020

We maintain dates for the issuance of ICA certificate with the same keys and without the EKU OCSP Signing, which we attach, and for the revocation of current certificates with EKU OCSP Signing.

We will ask this week to add to OneCRL the current ICA certificates and the new ones, except INFRAESTRUCTURA, as a mitigation means for OneCRL clients.

Issuance of new certificates with new keys: estimated week of July 27, 2020.

Once the new certificates appear in the Spanish TSL (this is a requirement for most of our clients who also rely in the TSL), we will begin the rollover of the still valid leaf certificates to the new ICA certificates with new key pairs and when the rollover is completed: revocation of the ICA certificates with the same keys and key destruction ceremony.

Clarifications:

  • Firmaprofesional has exclusive control of the private keys of all the CAs that are part of its hierarchy and thus declares it in its CPS
  • None of the affected ICA certificates of Firmaprofesional has the keyUsage digitalSignature
  • Only the ICA INFRASTRUCTURE issues SSL certificates.
  • The new INFRASTRUCTURE certificate with new keys will be the first in a series of CA Intermedia (ICA) certificates aimed at issuing secure server certificates that will follow this scheme:
    ** The ICA certificate will last no more than 3 years.
    ** ICA certificates will be renewed annually, with new keys
    ** For easier identification of the certificates, the year of issue will be added to the certificate, for example "AC FIRMAPROFESIONAL - Secure Web 2020"
Whiteboard: [ca-compliance] Next update 22-July-2020 → [ca-compliance]

New ICAs certificates w/o EKU OCSPSigning.

Updating information in: https://bugzilla.mozilla.org/show_bug.cgi?id=1651637

I am willing to close this bug and consolidate further discussion under Firmaprofesional's bug for delayed revocation, Bug #1651637. 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 Firmaprofesional takes to ensure it is following and participating in discussions that highlight these types of issues. For instance, I assume that Firmaprofesional 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.

Yes, we participate and following several source of information, especially CA/B Forum discussions and ballot proposal, md.s.p. and Bugzilla tiquets with subscription to new tiquets related with the Product/Component: NSS :: CA Certificate Compliance.

Closing - please refer to Bug 1651637 for further proceedings

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

Attachment

General

Creator:
Created:
Updated:
Size: