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

['Amir Omidi (aaomidi)' via dev-security-policy@mozilla.org]

I just wanted to point out that e-commerce's communication is still 
very-very delayed: https://bugzilla.mozilla.org/show_bug.cgi?id=1893546#c1, 
https://bugzilla.mozilla.org/show_bug.cgi?id=1862004#c9

I think e-commerce is getting into the territory where we should really 
consider if they're a healthy member of the Mozilla root store.

*Does anyone have any arguments on why e-commerce shouldn't be fast tracked 
to removal from root stores?* I know in the future we probably need to 
define certain criteria on how to handle non-responsive CAs such as this. 
But I don't think we should wait until such a document is prepared before 
taking action.

On Friday, May 3, 2024 at 9:12:19 AM UTC-4 Wayne wrote:

> Hi Andrew,
>
> I was looking at https://globaltrust.eu/certificate-policy/ and the 
> 'GLOBALTRUST 
> 2015 SERVER OV 2' entry which includes a list of test servers. I can see 
> there is a different list of test servers listed higher on the page, and 
> 2020 functions correctly, but 2015 has the same issue (from the 'Testserver 
> SSL-Zertifikate' heading):
>
> GLOBALTRUST 2015 gültiges Zertifikat 
> https://testok-2015-server-qualified-1.e-monitoring.at
> GLOBALTRUST 2015 abgelaufenes Zertifikat 
> https://testold-2015-server-qualified-1.e-monitoring.at
> GLOBALTRUST 2015 widerrufenes Zertifikat 
> https://testrevoked-2015-server-qualified-1.e-monitoring.at 
>
> This seems to have been an abandoned practice by globaltrust and the 
> entries are inconsistent on whether they have any listed.
>
> - Wayne
> On Friday, May 3, 2024 at 1:59:59 PM UTC+1 Andrew Ayer wrote:
>
>> Hi Wayne, 
>>
>> On Fri, 3 May 2024 04:29:15 -0700 (PDT) 
>> Wayne  wrote: 
>>
>> > They don't list valid/expired/revoked domains for all of their 
>> > sub-CAs 
>>
>> CAs are only required to provide one set of test websites per root, not 
>> for every sub-CA. 
>>
>> > and even the ones they do are running on the same wildcard 
>> > covering: 
>> > 
>> > DNS:timestamp.globaltrust.eu 
>> > DNS:*.globaltrust.eu 
>> > DNS:*.globaltrust.at 
>> > DNS:*.globaltrust.info 
>> > DNS:*.a-cert.at 
>> > DNS:*.e-monitoring.at 
>> > 
>> > See: https://crt.sh/?id=9532011580 
>>
>> Where are you seeing this disclosed as a test website certificate? The 
>> disclosures that I see in the CCADB for GLOBALTRUST's Mozilla-trusted 
>> root are: 
>>
>> https://testok-2020-server-qualified-ev-1.e-monitoring.at/ 
>> https://testold-2020-server-qualified-ev-1.e-monitoring.at/ 
>> https://testrevoked-2020-server-qualified-ev-1.e-monitoring.at/ 
>>
>> Those all look correct to me. 
>>
>> Regards, 
>> Andrew 
>>
>

-- 
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/d8b87251-a772-4777-8597-3918931fb7b3n%40mozilla.org.

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.