Distrust dates for GLOBALTRUST 2020 CA
Ben Wilson
All,
We appreciate the comments received from the community on m-d-s-p and in Bugzilla regarding several recent incidents involving e-commerce monitoring GmbH (ECM). A summary of the most recent Bugzilla incidents has been published on the Mozilla wiki, https://wiki.mozilla.org/CA/e-commerce-monitoring_Issues.
Public discussion and our review have highlighted long-running and unresolved compliance issues with ECM, including but not limited to (1) a failure to recognize, understand, and adhere to the compliance obligations of a publicly trusted CA, (2) repeated failure to meet the requirements for timely updates in line with incident reporting requirements (i.e. https://www.ccadb.org/cas/incident-report#incident-reports and https://wiki.mozilla.org/CA/Responding_To_An_Incident#Keeping_Us_Informed), and (3) inadequate responses, root cause analyses, and mitigations.
Problems with ECM's operations and compliance began surfacing in February 2023, with the mis-issuance of certificates reported in Bug 1815534 and further detailed in Bug 1830536. This revealed a substantial misunderstanding of root program requirements around timely incident response and rectification, leading to a delayed revocation incident (Bug 1862004). The overall finalization of these incident reports took over a year, completing in February 2024, due to both failures to include necessary information and excessive delays in responses by ECM.
These issues have intensified in recent months, with a mis-issuance reported in Bug 1883711, which was then revoked with the incorrect reason code. Numerous further issues emerged in the incident response, including excessive delays in responses, failure to disclosure a similarly mis-issued certificate that was revoked but not mentioned in the subsequent incident report, failure to promptly self-report the initial incident when the CA became aware of it, and failure to identify suitable preventative steps to address the root cause. This incident remains unresolved as of this post, and it is unclear that sufficient preventative actions have been taken by ECM.
In Bug 1888371 reported on March 28, 2024, ECM was discovered to be serving incorrectly signed CRLs, violating the CA/Browser Forum’s TLS Baseline Requirements. Although ECM attempted an initial fix which proved ineffective, ECM has now missed the target date they set for themselves for a solution (May 31, 2024), meaning that their revocation infrastructure for some of their certificates has been unavailable for over 70 days, and ECM has not given any update on their progress towards resolution for over 30 days.
ECM's general failure to respond in line with incident reporting requirements in a timely fashion is discussed further in Bug 1893546.
Mozilla’s expectations for all CA operators participating in its root store are clear: they must provide timely updates and effective resolutions to incidents, they must ensure that root cause analyses are thorough and promptly updated based on community feedback, and they must maintain adequate staffing and resources.
In light of ECM’s persistent issues, we will be setting “Distrust After” dates for websites and email trust bits associated with ECM’s GLOBALTRUST 2020 root CA, effective June 30, 2024. TLS server authentication and S/MIME certificates issued before June 30, 2024, will be unaffected by this change, but certificates issued after June 30, 2024, will not be trusted.
We want to clarify that although a separate assessment of ECM’s continued inclusion in Mozilla’s Root Store was underway due to their acquisition by AUSTRIA CARD, this decision to remove ECM is unrelated to that ownership change and should not be considered a negative finding against AUSTRIA CARD. Should AUSTRIA CARD or a related entity seek inclusion in Mozilla’s Root Store in the future, that application will be considered on its merits.
Sincerely yours,
Ben Wilson
Mozilla Root Program Manager
Ben Wilson
> In light of ECM’s persistent issues, we will be setting “Distrust After” dates for websites and email trust bits associated with ECM’s GLOBALTRUST 2020 root CA, effective June 30, 2024.
Hi Ben,
Will this be enforced solely based on NotBefore? Or will SCT timestamps be taken into account. If solely based on NotBefore, are you monitoring for backdated certificates in any way?
Thanks,-dadrian
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZMYjgxYAi72yPwcN3X_QJNqDUydpTyAuvmtBR9X80f1w%40mail.gmail.com.
Mike Shaver
Our long-term plan is to enhance our validity checking with CT.
Ben Wilson
On Tue, Jun 11, 2024 at 11:39 AM 'Ben Wilson' via dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> wrote:.
Mike Shaver
Here is the Bugzilla bug - https://bugzilla.mozilla.org/show_bug.cgi?id=1901080Ben
On Tuesday, June 11, 2024 at 9:43:33 AM UTC-6 Mike Shaver wrote:
On Tue, Jun 11, 2024 at 11:39 AM 'Ben Wilson' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote:.
Our long-term plan is to enhance our validity checking with CT.This is great to hear. Are there bugs that can be followed that cover the necessary work here (I assume in NSS and then in Firefox and Thunderbird)?Mike
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/8da8aab1-f87c-42b4-9a24-e3ae517dbd44n%40mozilla.org.
Ben Wilson
Andrew Ayer
I strongly encourage Mozilla to not use a distrust after date with this
CA and to distrust it outright, as was done with other untrustworthy
CAs like Certinomis and Camerfirma. Since Firefox does not require CT,
I would assume that any malicious backdated certificates will not be
logged and therefore no one will detect them.
According to CT, ECM has only 43 unexpired TLS certificates in
circulation, for a total of 84 distinct DNS names (see attached). (In
contrast, Certinmois had 1,381 unexpired certificates at the time that
they were removed -
https://bugzilla.mozilla.org/show_bug.cgi?id=1552374) If we exclude
ECM's own domains, this drops down to just 36 distinct DNS names.
Therefore, the compatibility risk of distrusting ECM is practically
nonexistent. If breaking these 36 sites is a concern, then I suggest
name constraining the root to the 13 eTLD+1s which use ECM (also
attached).
ECM's incidents should give us very little faith in the adequacy of
their controls. Continuing to trust their certificates on the basis of
the notBefore date will only prolong the time during which Firefox
users are at risk of security incidents involving ECM.
Regards,
Andrew
On Tue, 11 Jun 2024 08:59:25 -0600
>
> We appreciate the comments received from the community on m-d-s-p and
> in Bugzilla regarding several recent incidents involving e-commerce
> monitoring GmbH (ECM). A summary of the most recent Bugzilla
> incidents has been published on the Mozilla wiki,
> https://wiki.mozilla.org/CA/e-commerce-monitoring_Issues.
>
> Public discussion and our review have highlighted long-running and
> unresolved compliance issues with ECM, including but not limited to
> (1) a failure to recognize, understand, and adhere to the compliance
> obligations of a publicly trusted CA, (2) repeated failure to meet
> the requirements for timely updates in line with incident reporting
> requirements (i.e.
> https://www.ccadb.org/cas/incident-report#incident-reports and
> https://wiki.mozilla.org/CA/Responding_To_An_Incident#Keeping_Us_Informed),
> and (3) inadequate responses, root cause analyses, and mitigations.
>
> Problems with ECM's operations and compliance began surfacing in
> February 2023, with the mis-issuance of certificates reported in Bug
> timely incident response and rectification, leading to a delayed
> revocation incident (Bug 1862004
> in February 2024, due to both failures to include necessary
> information and excessive delays in responses by ECM.
>
> These issues have intensified in recent months, with a mis-issuance
> reported in Bug 1883711
> emerged in the incident response, including excessive delays in
> responses, failure to disclosure a similarly mis-issued certificate
> that was revoked but not mentioned in the subsequent incident report,
> failure to promptly self-report the initial incident when the CA
> became aware of it, and failure to identify suitable preventative
> steps to address the root cause. This incident remains unresolved as
> of this post, and it is unclear that sufficient preventative actions
> have been taken by ECM.
>
> proved ineffective, ECM has now missed the target date they set for
> themselves for a solution (May 31, 2024), meaning that their
> revocation infrastructure for some of their certificates has been
> unavailable for over 70 days, and ECM has not given any update on
> their progress towards resolution for over 30 days.
>
> ECM's general failure to respond in line with incident reporting
> requirements in a timely fashion is discussed further in Bug 1893546
>
> Mozilla___s expectations for all CA operators participating in its root
> resolutions to incidents, they must ensure that root cause analyses
> are thorough and promptly updated based on community feedback, and
> they must maintain adequate staffing and resources.
>
> After___ dates for websites and email trust bits associated with ECM___s
> authentication and S/MIME certificates issued before June 30, 2024,
> will be unaffected by this change, but certificates issued after June
> 30, 2024, will not be trusted.
>
> continued inclusion in Mozilla___s Root Store was underway due to their
> to that ownership change and should not be considered a negative
> finding against AUSTRIA CARD. Should AUSTRIA CARD or a related entity
>
> Sincerely yours,
>
> Ben Wilson
>
> Mozilla Root Program Manager
>
> You received this message because you are subscribed to the Google
> Groups "dev-secur...@mozilla.org" group. To unsubscribe from
> this group and stop receiving emails from it, send an email to
> dev-security-po...@mozilla.org. To view this discussion
> on the web visit
Ben Wilson
Although we have lost faith in ECM's ability to operate within the requirements of our root program, we've seen no evidence to suggest that they've engaged in or will engage in actively malicious behavior.
We will continue to
monitor the situation, and if evidence is found of misbehavior, then we will remove
the root certificate on an expedited timeline, but still, we won't be waiting a year before filing a root-removal bug.
Thanks,
Ben
Andrew Ayer
<dev-secur...@mozilla.org> wrote:
> Hi Andrew,
>
> Although we have lost faith in ECM's ability to operate within the
> requirements of our root program, we've seen no evidence to suggest
> that they've engaged in or will engage in actively malicious behavior.
>
> We will continue to monitor the situation, and if evidence is found of
> misbehavior, then we will remove the root certificate on an expedited
> timeline, but still, we won't be waiting a year before filing a
> root-removal bug.
>
> Thanks,
>
> Ben
My concern isn't malicious behavior by ECM, but rather their lax
practices leading to a compromise which allows attackers to get
unlogged, backdated certificates that are used to attack Firefox
users, which Mozilla would have no way of detecting. I'm particularly
worried that they seem to have checked out from being a CA, leaving a
CRL broken for over 60 days and not answering any more questions in
Bugzilla.
It's really hard to understand why the distrust is being done this way
in light of what I pointed out about the tiny number of websites that
would be impacted by immediate distrust. Could you explain the
reasoning some more?
Regards,
Andrew
Andrew Ayer
Andrew Ayer <ag...@andrewayer.name> wrote:
> If we exclude ECM's own domains, this drops down to just 36 distinct
> DNS names.
18 are serving a non-ECM certificate on port 443
9 are serving an ECM certificate on port 443
6 did not respond on port 443
3 are wildcard DNS names
Regards,
Andrew
Mike Shaver
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20240611155511.4871da6bf1be264046b9d62d%40andrewayer.name.
Wayne
Ben Wilson
Dear Andrew and all,
We understand your concerns.
We are evaluating and considering your suggestions.
Thanks,
Ben Wilson
Mozilla Root Program Manager
Mike Shaver
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/5b7a138e-ce79-4b12-a620-c95584e6fa46n%40mozilla.org.
e-commerce monitoring
The reasons for the removal have been comprehensively discussed Bugzilla forum. We acknowledged and accepted the decision. We have identified the shortcomings in our processes, particularly related to reaction time. Consequently, we are taking these issues very seriously and are committed to address them. An action plan is being rolled out to restructure our Certificate Authority (CA) functions. Our goal is to be included again in the Root Programs.
ECM’s shareholder, AUSTRIA CARD, is committed to regains full compliance with the Browser/OS Root Store Policies. This commitment, which is strongly supported by our recently changed management, underscores our dedication to maintaining the widest compatibility and coverage.
As an immediate action, and until full remediation, ECM has ceased the issuance of TLS certificates according to the CA/Browser Forum Requirements. TLS certificates will be provided solely based on Regulation (EU) No 910/2014, Annex IV, as recently amended by Regulation (EU) 2024/1183 (“QWACs”). Certificates for interoperability testing purposes are excluded from this decision.
ECM, with its product lines GLOBALTRUST and TRUST2GO, is a Qualified Trust Service Provider (QTSP) according to EU eIDAS regulation and is under continuous supervision by the Austrian regulatory authority (RTR/TKK). Our activities are regularly evaluated by an accredited conformity assessment body based on numerous standards (e.g., eIDAS, ETSI), which include comprehensive logical, physical, and organizational security measures.
Our goal is to rebuild trust and demonstrate our commitment to upholding the highest standards in our industry.
For inquiries, please contact the Compliance & Product Management team, Attn: Mr. Daniel Zens, at c...@globaltrust.eu