Re: Vulnurability Disclosure - How does it happen?

['Ben Wilson' via dev-security-policy@mozilla.org]

Amir,
To answer the last question first, Chunghwa Telecom did not disclose this
recent attack, but I don't think we have sufficient information from the
article to determine the effects of the breach on the CA operations. So
without more information, it might be premature to answer the question, "Is
a security incident like the one I posted above considered an instance of a
CA "failing to comply"?"
The process envisioned by the policy and guidance does contemplate that
these disclosures would be in a secure bug (to which Mozilla would grant
other root programs access). It also contemplates that another, public bug
would need to be created, using the incident-reporting template (including
a description of the CA's incident response). Finally, because this is a
new process, we do not yet have any experiences to share or to use in
evaluating the success or shortcomings of the requirement.
Ben

On Thu, May 23, 2024 at 9:54 AM 'Amir Omidi (aaomidi)' via
dev-security-policy@mozilla.org  wrote:

> Hey folks,
>
> I am bringing this up because of:
> https://www.darkreading.com/cyberattacks-data-breaches/taiwan-telco-breached-data-sold-on-dark-web
>
> (I've marked my questions in bold)
>
> I'm mainly basing this discussion around:
> https://wiki.mozilla.org/CA/Vulnerability_Disclosure. I want to
> understand what the intent of some of the wording in this is, and how it
> applies to CAs.
>
> In that wiki, we see:
>
> > Vulnerabilities/incidents that may “significantly impact the
> confidentiality, integrity, or availability” of a CA's internal systems,
> regardless of direct impact on certificate issuance, must be reported if
> they pose ongoing risk to the overall integrity and security of CA
> operations. This includes significant impact not just to issuing systems,
> but also to network and server security, internal software, and the
> availability and reliability of certificate status services, such as CRLs
> and OCSP.
>
> What is Mozilla's intent by the phrase "must be reported if they pose
> ongoing risk to the overall integrity and security of CA operations."
>
> More specifically:
>
>1. *"Disclosed" to whom? Public? Just Mozilla?*
>2. *What does "if they pose an ongoing risk" mean? If its a one-off
>attack, does that mean it does not need to be disclosed?*
>
> I'm also unsure about trusting CAs to determine the significance of such
> an attack. We've seen recently that a few CAs have really jumped to making
> claims such as "this incident has no security impact" before doing any
> proper RCA or even understanding the extent of the incident. *Has Mozilla
> found any issues with leaving the determination up to CAs in the past?*
>
> More broadly, how does this wiki work when read in conjunction with the 
> Mozilla
> Root Store Policy
> 
>
> Specifically, section 2.4:
>
> > When a CA operator fails to comply with any requirement of this policy -
> whether it be a misissuance, a procedural or operational issue, or any
> other variety of non-compliance - the event is classified as an incident
> and MUST be reported to Mozilla as soon as the CA operator is made aware.
>
> *Is a security incident like the one I posted above considered an instance
> of a CA "failing to comply"?*
>
> In 2.4.1 we see:
>
> > Additionally, and not in lieu of the requirement to publicly report
> incidents as outlined above, a CA Operator MUST disclose a serious
> vulnerability or security incident in Bugzilla
>  as a secure bug
> 
> in accordance with guidance found on the Vulnerability Disclosure wiki
> page .
>
> From my reading here, this means that all security vulnerabilities are
> being disclosed privately to Mozilla. I guess this *kind of* makes sense
> here.
>
> *Would Mozilla be open to having a limited cooling-off period where these
> secure bugs stay private, but after that period the information becomes
> public*?
>
> My justification for asking this is:
>
>- Other CAs can and should learn from how a CA responded to a security
>incident.
>- There may be commonalities in attack patterns that these incidents
>being public can help surface.
>- It reassures the community that these incidents are being taken
>seriously by allowing third parties to also verify and validate the
>incident response and mitigation items.
>
>
> Beyond this, *I'd also be interested in hearing if Chunghwa Telecom has
> disclosed the impact of this recent attack on their systems (if any) to
> Mozilla and the other root programs.*
>
>
> --
> You received this message because you are subscribed to the Google Groups "
> dev-security-policy@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> 

Re: Recent Entrust Compliance Incidents

['Ben Wilson' via dev-security-policy@mozilla.org]

Added " Although not expressed in the bug, it appears that certificate
revocation was delayed as well."

On Fri, May 10, 2024 at 10:54 AM George  wrote:

> Although it was not mentioned in the original bug, it may be worth adding
> that the certificates in bug 1867130
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1867130> were also not
> revoked within 5 days of discovery. Entrust might've based the start of the
> 5 day deadline at the time the "Director of compliance confirmed
> investigation conclusions to support team" at 2023-11-21 15:00 UTC with all
> certificates being revoked by 2023-11-26 14:50 UTC, but I don't think
> that's correct if that was the case.
>
> On Friday, May 10th, 2024 at 5:27 PM, 'Ben Wilson' via
> dev-security-policy@mozilla.org  wrote:
>
> Here are draft summaries of the additional historic incidents. I'll be
> adding these to the Entrust Issues page:
> https://wiki.mozilla.org/CA/Entrust_Issues
>
> *Invalid data in State/Province Field -*
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1658792
>
> It was initially discovered that Entrust had issued 395 OV SSL
> certificates to a large international organization with “NA” for the
> state/province information. Entrust worked on a drop-down list to prevent
> the error. Certificate revocation would not occur within established
> timeframes, so Bug #1658794 for delayed revocation was opened.
>
> *Late Revocation for Invalid State/Province Issue - *
> https://bugzilla.mozilla.org/show_bug.cgi?id=1658794
>
> This is the delayed revocation bug related to Bug #1658792, above. Entrust
> said that when educating large institutions about rapid revocation, factors
> include who owns a certificate, where it is deployed, and the type of
> system or application that requires the certificate. It also said that it
> was advocating automation with such institutions to help speed up
> certificate replacement and to minimize human error.
>
> *EV TLS Certificate incorrect jurisdiction -*
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1802916
>
> Entrust mis-issued 322 EV certificates with the wrong state and locality
> jurisdiction fields due to complex data entry processes. Entrust
> implemented a different automated dropdown system for jurisdiction
> selection. Certificate revocation would not occur within established
> timeframes, so Bug #1804753 for delayed revocation was opened.
>
> *Delayed Revocation for EV TLS Certificate incorrect jurisdiction - *
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1804753
>
> This is the delayed revocation bug related to Bug #1802916, above. Entrust
> listed 8 Subscribers who were pushing back on immediate certificate
> revocation and the reasons given (e.g. extensions granted due to
> end-of-year freezes). Entrust committed to “continue to develop and extend
> methods for automatic certificate renewal.”
>
> *Jurisdiction Locality Wrong in EV Certificate -*
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1867130
>
> Two EV TLS Certificates were mis-issued due to human error in the
> Jurisdiction Locality field. (The incident revealed 340 additional accounts
> needing similar updates.) Entrust said it would enhance its linting
> processes to include possibly using an external service to validate
> locality data against verified country data.
>
> *SHA-256 hash algorithm used with ECC P-384 key - *
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1648472
>
> A Mozilla policy was adopted to require hashing with SHA-384 for an ECC
> P-384 key. Existing CAs using SHA-256 were not re-configured when Mozilla
> adopted this policy. This incident revealed a serious gap in taking new
> requirements and implementing them. Ryan Sleevi noted that linting was just
> a safety net and not a systemic solution. Entrust was also criticized for
> the lack of detail in its incident report and its decision to not revoke
> the certificates.
>
> Entrust committed to improving its monitoring and implementation of policy
> changes to prevent similar incidents. Ryan set forth a number of proactive
> systemic corrections that Entrust needed to take, rather than taking a
> reactive stance on matters of non-compliance.
>
> Entrust committed to rigorous review of certificate profiles, browser
> policy revisions, and industry developments. As a final comment, Ryan said,
> “My big concern is, going forward, we see incident reports from Entrust
> take a more systemic, holistic response, like Comment #16, to try and cover
> the scenarios, and to provide sufficient detail about the situation and its
> failures to understand how those relate. The goal isn't to make CAs wear
> proverbial sackcloth, it's to try and make sure we're understanding how
>

Re: Recent Entrust Compliance Incidents

['Ben Wilson' via dev-security-policy@mozilla.org]

 PM Watson Ladd  wrote:

> Could we add a section for geographical incidents? This is slightly
> outside your time window, but I think reading the series here has some
> uncanny echos in the ones in your window.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1658792
> https://bugzilla.mozilla.org/show_bug.cgi?id=1658794
> https://bugzilla.mozilla.org/show_bug.cgi?id=1802916
> https://bugzilla.mozilla.org/show_bug.cgi?id=1804753
> https://bugzilla.mozilla.org/show_bug.cgi?id=1867130
>
> On Tue, May 7, 2024 at 7:59 AM 'Ben Wilson' via
> dev-security-policy@mozilla.org 
> wrote:
> >
> > Dear Mozilla Community,
> >
> > Over the past couple of months, a substantial number of compliance
> incidents have arisen in relation to Entrust. We have summarized these
> recent incidents in a dedicated wiki page:
> https://wiki.mozilla.org/CA/Entrust_Issues. In brief, these incidents
> arose out of certificate mis-issuance due to a misunderstanding of the EV
> Guidelines, followed by numerous mistakes in incident handling (including a
> deliberate decision to continue mis-issuance), which have been compounded
> by a failure to remediate the issues in a timely fashion in line with
> well-established norms and root store requirements.
> >
> > Our preliminary assessment of these incidents is that while they were
> relatively minor initially, the poor incident response has substantially
> aggravated them and the progress towards full remediation remains
> unacceptably slow. This is particularly disappointing in light of previous
> incidents in 2020 (#1651481 and #1648472), which arose out of similar
> misunderstandings of the requirements, similar poor decision-making in the
> initial response, and lengthy remediation periods that fell well below
> expectations. Entrust gave commitments in those bugs to address the root
> problems through process improvements, and it is concerning to see so
> little improvement 4 years later.
> >
> > In light of these recent incidents, we are requesting that Entrust
> produce a detailed report of them. This report should cover in detail:
> >
> > The factors and root causes that lead to the initial incidents,
> highlighting commonalities among the incidents and any systemic failures;
> >
> > Entrust’s initial incident handling and decision-making in response to
> these incidents, including any internal policies or protocols used by
> Entrust to guide their response and an evaluation of whether their
> decisions and overall response complied with Entrust’s policies, their
> practice statement, and the requirements of the Mozilla Root Program;
> >
> > A detailed timeline of the remediation process and an apportionment of
> delays to root causes; and
> >
> > An evaluation of how these recent issues compare to the historical
> issues referenced above and Entrust’s compliance with its previously stated
> commitments.
> >
> > Finally, Entrust’s report should include a detailed proposal on how it
> plans to address the root causes of these issues. In light of previous
> guarantees given by Entrust in 2020 to ensure speedy remediation in future
> incidents, this proposal should include:
> >
> > Clear and concrete steps that Entrust proposes to take to address the
> root causes of these incidents and delayed remediation;
> >
> > Measurable and objective criteria for Mozilla and the community to
> evaluate Entrust’s progress in deploying these solutions; and
> >
> > A timeline for which Entrust will commit to meeting these criteria.
> >
> > We strongly recommend that Entrust go beyond their existing commitment
> to offer systematic, automated solutions for effective remediation, like
> ACME ARI and that it also include clear and measurable targets for the
> adoption of these tools by new and existing subscribers.
> >
> > This report should be submitted to Mozilla dev-security-policy mailing
> list for evaluation by the community and Mozilla, who will weigh whether
> Entrust’s report presents a credible and effective path towards
> re-establishing trust in Entrust’s operation. Submission should be no later
> than June 7, 2024.
> >
> > We thank community members for their engagement on these issues and look
> forward to their feedback on Entrust’s report and proposed commitments.
> >
> >  Thanks,
> >
> > Ben Wilson
> >
> > Mozilla Root Program
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "dev-security-policy@mozilla.org" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to dev-security-policy+unsubscr...@moz

Recent Entrust Compliance Incidents

['Ben Wilson' via dev-security-policy@mozilla.org]

Dear Mozilla Community,

Over the past couple of months, a substantial number of compliance
incidents have arisen in relation to Entrust. We have summarized these
recent incidents in a dedicated wiki page:
https://wiki.mozilla.org/CA/Entrust_Issues. In brief, these incidents arose
out of certificate mis-issuance due to a misunderstanding of the EV
Guidelines, followed by numerous mistakes in incident handling (including a
deliberate decision to continue mis-issuance), which have been compounded
by a failure to remediate the issues in a timely fashion in line with
well-established norms and root store requirements.

Our preliminary assessment of these incidents is that while they were
relatively minor initially, the poor incident response has substantially
aggravated them and the progress towards full remediation remains
unacceptably slow. This is particularly disappointing in light of previous
incidents in 2020 (#1651481
 and #1648472
), which arose out of
similar misunderstandings of the requirements, similar poor decision-making
in the initial response, and lengthy remediation periods that fell well
below expectations. Entrust gave commitments
 in those bugs to
address the root problems through process improvements, and it is
concerning to see so little improvement 4 years later.

In light of these recent incidents, we are requesting that Entrust produce
a detailed report of them. This report should cover in detail:

   -

   The factors and root causes that lead to the initial incidents,
   highlighting commonalities among the incidents and any systemic failures;
   -

   Entrust’s initial incident handling and decision-making in response to
   these incidents, including any internal policies or protocols used by
   Entrust to guide their response and an evaluation of whether their
   decisions and overall response complied with Entrust’s policies, their
   practice statement, and the requirements of the Mozilla Root Program;
   -

   A detailed timeline of the remediation process and an apportionment of
   delays to root causes; and
   -

   An evaluation of how these recent issues compare to the historical
   issues referenced above and Entrust’s compliance with its previously stated
   commitments.

Finally, Entrust’s report should include a detailed proposal on how it
plans to address the root causes of these issues. In light of previous
guarantees  given
by Entrust in 2020 to ensure speedy remediation in future incidents, this
proposal should include:

   -

   Clear and concrete steps that Entrust proposes to take to address the
   root causes of these incidents and delayed remediation;
   -

   Measurable and objective criteria for Mozilla and the community to
   evaluate Entrust’s progress in deploying these solutions; and
   -

   A timeline for which Entrust will commit to meeting these criteria.

We strongly recommend that Entrust go beyond their existing commitment
 to offer
systematic, automated solutions for effective remediation, like ACME ARI
and that it also include clear and measurable targets for the adoption of
these tools by new and existing subscribers.

This report should be submitted to Mozilla dev-security-policy mailing list
for evaluation by the community and Mozilla, who will weigh whether
Entrust’s report presents a credible and effective path towards
re-establishing trust in Entrust’s operation. Submission should be no later
than June 7, 2024.

We thank community members for their engagement on these issues and look
forward to their feedback on Entrust’s report and proposed commitments.

 Thanks,

Ben Wilson

Mozilla Root Program

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYURqFzRqVmJdc7fBXE1mbGs25HpSkp5wZ0Xm%2BRG0YHCA%40mail.gmail.com.

Re: comment on Entrust_Issues wiki page

['Ben Wilson' via dev-security-policy@mozilla.org]

All,
I hadn't announced this page yet, hoping to reference it in an email
currently undergoing internal review. But thanks for your comment.
I'll see about posting the email as soon as I can.
Thanks,
Ben

On Mon, May 6, 2024 at 3:58 PM Mike Shaver  wrote:

> The page lists the following issue:
>
> “
> 5. EV Certificate missing Issuer’s EV Policy OID -
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1888714
>
> Entrust issued 1,963 EV TLS certificates September 11-22, 2023, without
> including an EV TLS CP OID. Root Causes were the misinterpretation of the
> EV Guidelines and the TLS BRs and a failure to recognize the overriding
> requirements of the EV Guidelines. (A misinterpretation of standards led to
> non-compliant certificates, and linting failed to detect the issue.) As
> remediation, since April 11, 2024, Entrust has used pkilint as a
> post-issuance linter to detect similar issues. (Mis-issued certificates are
> a subset of the certificates disclosed and being revoked under bug
> #1883843 . Status
> of revocation is listed in bug #1886532
> .)
>
> *Issues:* Misinterpretation of Requirements; Policy/Procedure Failure;
> Certificate Mis-issuance”
>
> In my opinion it should also list that Entrust promised to provide a full
> list of affected certs and an incident report by April 5th, and continued
> to comment in the bug, but did not post that list or the IR until April
> 10th. No comment was made about a delay, or the reason that it was
> necessary.
>
> Mike
>
>
> --
> You received this message because you are subscribed to the Google Groups "
> dev-security-policy@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dev-security-policy+unsubscr...@mozilla.org.
> To view this discussion on the web visit
> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqsbubH8_7-NNxC7E7FbV%2BCqBPF%3DaYR2GseNCjy1mqEXHA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabKSQhyHSPeh6iEki4mkH9Kkky0Wpes8YyB2-xsEnNu1w%40mail.gmail.com.

Re: Public Discussion of Acquisition of e-commerce monitoring GmbH by AUSTRIA CARD-Plastikkarten und Ausweissysteme GmbH

['Ben Wilson' via dev-security-policy@mozilla.org]

Hi Amir,

Here is a quick update on this issue, while I continue working on a summary
of the discussion concerning the acquisition of e-commerce monitoring by
AUSTRIA CARD.

Since June 1, 2022, section 3.2 of the Mozilla Root Store Policy (MRSP) has
required that ETSI auditors be members of the Accredited Conformity
Assessment Bodies' Council (ACAB'c). One of the underlying reasons for
adopting this requirement was to ensure consistency in auditor
qualifications, guidance, and attestation letters. The ACAB’c membership
requirement continues to help improve the quality of ETSI audits. However,
the MRSP also allows Mozilla to temporarily waive the ACAB’c membership
requirement under certain circumstances.

e-commerce monitoring’s ETSI audit is currently performed by A-SIT (Secure
Information Technology Center – Austria). According to Herbert Leithold,
Executive Director of A-SIT, “A-SIT is a government-funded information
security organisation with formal duties that require strict neutrality and
independency.” For this reason, A-SIT asserts that it is precluded from
joining the ACAB’c. While A-SIT is currently not a member of ACAB'c, it has
otherwise met auditor qualification requirements and its audits have
conformed to templates provided by the ACAB’c.

We are considering whether to grant a temporary approval of A-SIT as an
exception to the ACAB’c membership requirement. Such temporary approval
would be subject to periodic re-evaluation, and likely it would eventually
be withdrawn. We sincerely appreciate everyone's contributions as they
facilitate our ability to make well-informed decisions. We kindly request
your insightful perspectives and opinions.

Thanks,

Ben


On Fri, Apr 26, 2024 at 12:09 PM Amir Omidi (aaomidi) 
wrote:

> Did you ever hear from them?
>
> On Tuesday, March 5, 2024 at 11:18:13 AM UTC-5 Ben Wilson wrote:
>
>> All,
>> March 1 was the scheduled end of public discussion on this matter.
>> However, I have one unresolved question that I have presented to the CA
>> operator and its audit firm regarding ACAB'c membership (see MRSP section
>> 3.2). As soon as I hear back on that question, I'll provide a summary of
>> the entire discussion here.
>> Thanks,
>> Ben
>>
>> On Friday, February 23, 2024 at 7:36:13 AM UTC-7
>> regist...@e-monitoring.at wrote:
>>
>>> *Preface*
>>>
>>> The only thing that changed is the ownership, and the ownership is
>>> represented by the new management. This only formal change has already been
>>> notified to the authorities and approved and registered. The rest remains
>>> unchanged.
>>>
>>> e-commerce monitoring GmbH fulfills different trust service requirements
>>> from ISO/IEC, eIDAS / ETSI, CA/Browser Forum to Root Program requirements,
>>> remains a member of the European Trust List (EUTL) as before and is
>>> permanently monitored by the Austrian Supervisory Body (RTR/TKK) and
>>> regularly assessed by a Conformity Assessment Body.
>>>
>>> The management has changed from Hans G. Zeger to Emmanouil Kontos and
>>> Markus Kirchmayr. The takeover of the company includes the taking over of
>>> the existing, trained and trusted staff which results in no changes except
>>> top management. e-commerce monitoring GmbH continues to provide
>>> certification and trust services according to the respective policies.
>>>
>>> It is in the interest of AUSTRIA CARD-Plastikkarten und Ausweissysteme
>>> Gesellschaft m.b.H. that e-commerce monitoring GmbH continues to fully
>>> comply with the Browser/OS Root Store Policies.
>>>
>>>
>>> *Ownership and Governance*
>>>
>>> The ultimate beneficial owner is Nikolaos Lykos. The new shareholder of
>>> e-commerce monitoring GmbH is AUSTRIA CARD-Plastikkarten und Ausweissysteme
>>> Gesellschaft m.b.H., Nikolaos Lykos owns 77.57 % of shares in AUSTRIACARD
>>> HOLDINGS AG, which is the parent company of AUSTRIA CARD-Plastikkarten und
>>> Ausweissysteme Gesellschaft m.b.H. (it is owned 100% by AUSTRIACARD
>>> HOLDINGS AG).
>>>
>>> AUSTRIACARD HOLDINGS AG is a publically listed company with subsidiaries
>>> in Europe and the USA (please find more details in the prospectus on
>>> AUSTRIACARD´s website (
>>> https://www.austriacard.com/wp-content/uploads/2023/01/AustriaCard_Prospectus_24.01.2023_FINAL.PUBLICATIONpdf.pdf
>>> )
>>>
>>> Emmanouil Kontos is the Managing Director of the company and authorized
>>> to represent the company solely. Markus Kirchmayr is authorized to
>>> represent the company jointly with Emmanouil Kontos. Both will not take any
>>> trusted roles in the CA operations.
>>>
>>> e-commerce monitoring GmbH is maintaining the Key Management as well as
>>> the respective roles of Key Manager and Key Custodian through the existing,
>>> trained and trusted staff
>>>
>>> Major decisions regarding finance and management topics are made by the
>>> Managing Director Emmanouil Kontos in consultation with Markus Kirchmayr
>>> Major decisions regarding operative topics are made by the Managing
>>> Director Emmanouil Kontos in