Re: Financial incentive against security ( was Re: [EXTERNAL] Recent Entrust Compliance Incidents)

[Mike Shaver]

Apologies, I somehow managed to send white-on-white HTML from gmail mobile
and I honestly have no idea how.

On Sat, Jun 8, 2024 at 9:48 PM Jeffrey Walton  wrote:

> I would caution against that. Effectively, Mozilla would be fiddling

> with the market. The market should be the one to punish (or reward)

> Entrust for the premiums on manual issuance, not Mozilla. When

> subscribers get tired of paying too much for the service, the customer

> will go elsewhere.

Hey, uh, yeah…Mozilla sort of exists to “fiddle with the market” in ways
that it feels protect the web’s users from the direction that The Market
might otherwise take. It’s sort of “their thing”.

But that rather jarring dissonance aside, nobody is objecting to premiums
on manual issuance. It is precisely the opposite: it is an objection to
charging Subscribers *extra* for using *automated* tools that make the web
safer (and which indeed should be cheaper for the CA to operate than a
manual process, but you know how it is with rent seeking).

The CA’s primary responsibility is to the web’s users, not to its
customers. They all know this. It can require that they not always optimize
for short-term business outcomes, but if they are not comfortable with that
*very* explicit tension, then this is not an appropriate business for them.

> In my mind's eye, there are two things to observe. First is the

> CA/Browser Standards ("what we do"), and second is the CA Operating

> Procedures ("how we do it").

I guess that is a way that these things could have evolved in a parallel
universe, but you have perhaps noticed that the BRs already have many
directions as to how things must be done. The BRs are in fact growing more
such directions over time as it becomes increasingly clear that not all CAs
can be trusted to do the things that are best for the health of the WebPKI;
see the active discussion about linting practices in the SCWG, for example.
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/CADQzZqsht5cWiudPMaV6VMDvp8jgO6qPnvr_U-KoXVfp%2BfWwGQ%40mail.gmail.com.

Re: Financial incentive against security ( was Re: [EXTERNAL] Recent Entrust Compliance Incidents)

[Mike Shaver]

On Sat, Jun 8, 2024 at 9:48 PM Jeffrey Walton  wrote:

> I would caution against that. Effectively, Mozilla would be fiddling
> with the market. The market should be the one to punish (or reward)
> Entrust for the premiums on manual issuance, not Mozilla. When
> subscribers get tired of paying too much for the service, the customer
> will go elsewhere.


Hey, uh, yeah…Mozilla sort of exists to “fiddle with the market” in ways
that it feels protect the web’s users from the direction that The Market
might otherwise take. It’s sort of “their thing”.

But that rather jarring dissonance aside, nobody is objecting to premiums
on manual issuance. It is precisely the opposite: it is an objection to
charging Subscribers *extra* for using *automated* tools that make the web
safer (and which indeed should be cheaper for the CA to operate than a
manual process, but you know how it is with rent seeking).

The CA’s primary responsibility is to the web’s users, not to its
customers. They all know this. It can require that they not always optimize
for short-term business outcomes, but if they are not comfortable with that
*very* explicit tension, then this is not an appropriate business for them.

In my mind's eye, there are two things to observe. First is the
> CA/Browser Standards ("what we do"), and second is the CA Operating
> Procedures ("how we do it").


I guess that is a way that these things could have evolved in a parallel
universe, but you have perhaps noticed that the BRs already have many
directions as to how things must be done. The BRs are in fact growing more
such directions over time as it becomes increasingly clear that not all CAs
can be trusted to do the things that are best for the health of the WebPKI;
see the active discussion about linting practices in the SCWG, for example.

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/CADQzZqvO%3DtCg3E0BGm-D%2Bo6AMnbuaEH0ZatG9PPmfdoYUjMKjQ%40mail.gmail.com.

Re: Financial incentive against security ( was Re: [EXTERNAL] Recent Entrust Compliance Incidents)

[Jeffrey Walton]

On Sat, Jun 8, 2024 at 6:15 PM Watson Ladd  wrote:
>
> On Sat, Jun 8, 2024 at 2:15 PM Mike Shaver  wrote:
> >"It would mean that revenue from the financial disincentive that Entrust 
> >puts in place against Subscriber automation (I believe it's called 
> >"SUB-PKI-CEG-ACME")"
>
> So for four years, while Entrust told us it was working to get its
> subscribers to automate, it was using this as a revenue opportunity
> thus continuing manual processes? There is no way to reconcile this
> with any sort of commitment here on Entrusts part to getting
> subscribers to automate.
>
> Could Mozilla update the root store policy to make clear that
> improvements like ACME shouldn't be extra cost items but instead
> considered part of the service provided to customers.

I would caution against that. Effectively, Mozilla would be fiddling
with the market. The market should be the one to punish (or reward)
Entrust for the premiums on manual issuance, not Mozilla. When
subscribers get tired of paying too much for the service, the customer
will go elsewhere.

In my mind's eye, there are two things to observe. First is the
CA/Browser Standards ("what we do"), and second is the CA Operating
Procedures ("how we do it"). The Browsers and collective CA's should
focus on the standard (what should be done), and each individual CA
should focus on the implementation (how it is done). The Forum should
not meddle in everyday affairs of a particular CA.

I understand the community wishes to punish Entrust for its chronic
problems. The CA/Browser Forum do not have tools for that, sans
delisting a particular CA. Maybe the CA/Browser Forum needs to adopt
some punishments, like forbidding a CA from issuing OV certificates or
EV certificates for a specified period of time, like a year. Or forbid
the CA from issuing other types of certificates, like S/MIME and code
signing certificates. The year embargo and lost revenue should be
enough of a haircut to get the CA to comply. If a CA continues to defy
the Forum, then delist the CA. There is plenty of competition in the
marketplace, so any particular CA will not be missed.

And remember, there are three parties in the ecosystem. The Browsers
and CA's are only two of them. There are also 5.35 billion relying
parties who use the internet. If the Forum wishes to acknowledge the
interests of the 5.35 billion internet users, then maybe removing
Entrust would be the best course of action. That's because Entrust
only seems to care about itself and its subscribers. It does not seem
to care about the the Forum, the standards produced by the Forum, or
the relying parties. Entrust has lost the trust of the community, and
that is the only commodity that matters to the relying parties.

Jeff

-- 
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/CAH8yC8%3DEqbCxtp8yc5GRS6kxBPrnxy0J3mMZUg3cX1tSjhZ%3DRQ%40mail.gmail.com.

Re: Financial incentive against security ( was Re: [EXTERNAL] Recent Entrust Compliance Incidents)

[Mike Shaver]

On Sat, Jun 8, 2024 at 6:29 PM Paul Wouters  wrote:

>
> > On Jun 8, 2024, at 18:16, Watson Ladd  wrote:
> >
> > 
> > Could Mozilla update the root store policy to make clear that
> > improvements like ACME shouldn't be extra cost items but instead
> > considered part of the service provided to customers.
>
> I don’t have an opinion on this but as someone who at $dayjob has been
> forced to request non-acme certificates manually, let me assure you that
> any vendor requiring me to do that quickly gets pulled in the “vendors to
> migrate away from” list. Any CA preferring manual issuance over automated
> issuance is going to find itself out of business soon (as are vendors
> providing web services requiring their customers to send them certs once a
> year manually while promising to support acme “soon”)


I guess that’s a nice assurance, but what does “soon” mean? July? Are you
buying enough certs to swing the economics of a major CA?

The problem right now is Subscribers who *don’t* want to adopt automation,
perhaps in part because Entrust would charge them extra for it. They are
the excuse being used too frequently for the dereliction of duty.

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/CADQzZqu0gZvsUZhbh4rnRHdKEuK3FqenSZ-D-Tyu0wQHp3aB7g%40mail.gmail.com.

Re: Financial incentive against security ( was Re: [EXTERNAL] Recent Entrust Compliance Incidents)

[Mike Shaver]

On Sat, Jun 8, 2024 at 6:15 PM Watson Ladd  wrote:

> On Sat, Jun 8, 2024 at 2:15 PM Mike Shaver  wrote:
> >"It would mean that revenue from the financial disincentive that Entrust
> puts in place against Subscriber automation (I believe it's called
> "SUB-PKI-CEG-ACME")"
>
> So for four years, while Entrust told us it was working to get its
> subscribers to automate, it was using this as a revenue opportunity
> thus continuing manual processes? There is no way to reconcile this
> with any sort of commitment here on Entrusts part to getting
> subscribers to automate.


I find it hard to come to any other interpretation of the facts.

Could Mozilla update the root store policy to make clear that
> improvements like ACME shouldn't be extra cost items but instead
> considered part of the service provided to customers.


I think that would be an exceedingly reasonable change for Mozilla to make
to its root store policy, personally.

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/CADQzZqvHZ31h%2BYBbUAK8yJ69TX7E02M%2Bz_DTyxp-%2BFP_K9nS%3Dw%40mail.gmail.com.

Financial incentive against security ( was Re: [EXTERNAL] Recent Entrust Compliance Incidents)

[Watson Ladd]

On Sat, Jun 8, 2024 at 2:15 PM Mike Shaver  wrote:
>"It would mean that revenue from the financial disincentive that Entrust puts 
>in place against Subscriber automation (I believe it's called 
>"SUB-PKI-CEG-ACME")"

So for four years, while Entrust told us it was working to get its
subscribers to automate, it was using this as a revenue opportunity
thus continuing manual processes? There is no way to reconcile this
with any sort of commitment here on Entrusts part to getting
subscribers to automate.

Could Mozilla update the root store policy to make clear that
improvements like ACME shouldn't be extra cost items but instead
considered part of the service provided to customers.

Sincerely,
Watson Ladd

-- 
Astra mortemque praestare gradatim

-- 
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/CACsn0c%3Dgnj7kRRsacN5u%3D%2BGpX2cBTxcEtY8mNRJEV5rmcUxYZw%40mail.gmail.com.

Re: [EXTERNAL] Recent Entrust Compliance Incidents

[Mike Shaver]

On Sat, 11 May 2024 at 15:04, 'Chris Bailey' via
dev-security-policy@mozilla.org  wrote:

> To that end, I want to confirm our intent to provide a full written
> response to you and the community prior to June 7.
>
> o_o

> a full written response to you and the community prior to June 7.
>
>  o_O

> prior to June 7
>

O___O

Date: Fri, 7 Jun 2024 12:53:10 -0700 (PDT)
From: "'Bruce Morton' via dev-security-policy@mozilla.org"

To: "dev-security-policy@mozilla.org" 
Cc: Ben Wilson 
Subject: Re: Recent Entrust Compliance Incidents

In another context, I would think this to not even be worth joking about,
but here it's just the cherry on the top of this whole process.

I have time booked this week to go through the report in more detail (every
time I start I turn over another thing that is wrong? it's fractal) but I
have to say, now that we've reached the end of this part of the process,
that I find Entrust's response--in specific and in general--to be well
beneath not only the expectations but indeed the mere *dignity* of the
Mozilla root program process, the CA/BF commitments, and the trusted role
that Entrust seems to so arrogantly believe cannot be lost.

I am generally known as a pretty charitable person, and in the mists of
time when I was responsible for the Mozilla root CA process I very often
advocated or outright decided in favour of using incidents as a tool for
learning far beyond being a tool for culling underperforming CAs from our
root store. Even at the point at which Ben posted the (extremely
understated) message beginning this thread, I had hoped that we would see
Entrust wake up from its long operational-quality slumber. I had hoped,
sincerely, that Entrust would provide plans that were transparent,
concrete, thorough, and sufficiently evident of meaningful reflection that
the response would be celebrated as an improvement in the health of the
WebPKI. It would mean that revenue from the financial disincentive that
Entrust puts in place against Subscriber automation (I believe it's called
"SUB-PKI-CEG-ACME") might in some small way be put towards strengthening
the integrity of the web's security. I was bewildered by the non-responses
that kept appearing in the bugs, but honestly I'm a sucker so I remained
hopeful. There were VPs involved, Entrust values its security brand so
much, their history is so long (I was doing infosec in the Ottawa area in
the early 90s)--they were going to come through now that it had been made
so abundantly clear that things were structurally broken.

Sadly, I then opened the response posted by Bruce.

When I first read the CPS URI incident, it seemed that Entrust thought that
the Mozilla root community wasn't watching them. (To be sure, there had
been some evidence in the preceding 4 years that this was the case.)

When the demeanour of Entrust's responses changed immediately after Ryan
Dickson of the Chrome Root Program entered the bug, it made me feel that
Entrust thought that the Mozilla root program and community didn't matter,
and that their commitments to that program were not meaningful.

When the third spokesperson, of increasing seniority, restated Entrust's
earnestness and pedigree without any actual concrete, measurable
commitments, I started to suspect that Entrust thought that they could just
"post through it", as the kids say.

But when I read this report, and especially when I compare it to the
exceptionally clear request from Ben in his original message, I can only
conclude that Entrust believes that this community and its participants are
in fact medically-grade stupid.

I honestly hope that someone there is ashamed of this.

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/CADQzZqtWvCAGMv97b5eJK_XqajGuAbhVFq_AUX85CxAZXyDWkg%40mail.gmail.com.

Re: Recent Entrust Compliance Incidents

[Wayne]

While Entrust have not provided details on their incident handling and 
decision-making as requested in this report, a few details have came to 
light in a reply to an incident today. This is specifically regarding 
#1886532 the delayed revocation CPSuri certificates.

https://bugzilla.mozilla.org/show_bug.cgi?id=1886532#c51

I will do this mailing a list a courtesy by not embedding it all, however I 
feel that similar details not being included for all of these incidents in 
this report already is troublesome. This comment shows that Entrust has all 
of this information available, they just did not feel it worth including 
despite it being asked for.
On Friday, June 7, 2024 at 11:42:34 PM UTC+1 Watson Ladd wrote:

> Dear Bruce,
>
> This report is completely unsatisfactory. It starts by presuming that
> the problem is 4 incidents. Entrust is always under an obligation to
> explain the root causes of incidents and what it is doing to avoid
> them as per the CCADB incident report guidelines. That's not the
> reason Ben and the community need this report. Rather it's to go
> beyond the incident report to draw broader lessons and to say more to
> help us judge Entrust's continued ability to stay in the root store.
> The report falls short of what was asked for, in a way that makes me
> suspect that Entrust is organizationally incapable of reading a
> document, understanding it, and ensuring each of the clearly worded
> requests is followed. The implications for being a CA are obvious.
>
> To start Ben specifically asked for an analysis involving the
> historical run of issues and a comparison. I don't see that in this
> report, at all. The list of incidents only has ones from 2024 listed,
> there's no discussion of the two issues specifically listed by Ben in
> his email.
>
> Secondly the remedial actions seem to be largely copy pasted from
> incident to incident without a lot of explanation. Saying the
> organizational structure will be changed to enhance support,
> governance and resourcing really doesn't leave us with a lot of
> ability to judge success or explain how the changes made (sparse on
> details) will lead to improvements. Similarly process weaknesses are
> not really discussed in ways that make clear what happened. How can I
> use this report if I was a different CA to examine my organization and
> see if I can do better? How can we as a community judge the adequacy
> of the remedial actions in this report?
>
> Section 2.4 I find mystifying. To my mind there's no inherent
> connection between a failure to update public information in a place
> it appears, a delay in reconfiguring a responder, and a bug in the CRL
> generation process beyond the organizational. These are three separate
> functions of rather different complexity. If there's a similarity it's
> between the latter two issues where there was a failure to notice a
> change in requirements that required action, but that's not what the
> report says! Why were these three grouped together, and not others?
> What's the common failure here that doesn't exist with the other
> incidents?
>
> If this is the best Entrust can do, why should we expect Entrust to be
> worthy of inclusion in the future? To be clear, there are CAs that
> have come back from profound failures of governance and judgement. But
> the first step in that process has been a full and honest accounting
> of what their failures have been, in a way that has helped others
> understand where the risks are and helps the community understand why
> they are trustworthy.
>
> Sincerely,
> Watson Ladd
> --
> Astra mortemque praestare gradatim
>

-- 
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/e374c341-8de4-4be3-9e5c-89a8feab1aadn%40mozilla.org.

Re: Recent Entrust Compliance Incidents

[Watson Ladd]

Dear Bruce,

This report is completely unsatisfactory. It starts by presuming that
the problem is 4 incidents. Entrust is always under an obligation to
explain the root causes of incidents and what it is doing to avoid
them as per the CCADB incident report guidelines. That's not the
reason Ben and the community need this report. Rather it's to go
beyond the incident report to draw broader lessons and to say more to
help us judge Entrust's continued ability to stay in the root store.
The report falls short of what was asked for, in a way that makes me
suspect that Entrust is organizationally incapable of reading a
document, understanding it, and ensuring each of the clearly worded
requests is followed. The implications for being a CA are obvious.

To start Ben specifically asked for an analysis involving the
historical run of issues and a comparison. I don't see that in this
report, at all.  The list of incidents only has ones from 2024 listed,
there's no discussion of the two issues specifically listed by Ben in
his email.

Secondly the remedial actions seem to be largely copy pasted from
incident to incident without a lot of explanation. Saying the
organizational structure will be changed to enhance support,
governance and resourcing really doesn't leave us with a lot of
ability to judge success or explain how the changes made (sparse on
details) will lead to improvements. Similarly process weaknesses are
not really discussed in ways that make clear what happened. How can I
use this report if I was a different CA to examine my organization and
see if I can do better? How can we as a community judge the adequacy
of the remedial actions in this report?

Section 2.4 I find mystifying. To my mind there's no inherent
connection between a failure to update public information in a place
it appears, a delay in reconfiguring a responder, and a bug in the CRL
generation process beyond the organizational. These are three separate
functions of rather different complexity. If there's a similarity it's
between the latter two issues where there was a failure to notice a
change in requirements that required action, but that's not what the
report says! Why were these three grouped together, and not others?
What's the common failure here that doesn't exist with the other
incidents?

If this is the best Entrust can do, why should we expect Entrust to be
worthy of inclusion in the future? To be clear, there are CAs that
have come back from profound failures of governance and judgement. But
the first step in that process has been a full and honest accounting
of what their failures have been, in a way that has helped others
understand where the risks are and helps the community understand why
they are trustworthy.

Sincerely,
Watson Ladd
--
Astra mortemque praestare gradatim

-- 
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/CACsn0ckZYa-Ycz0XFMpJNp7ECih5Ghy_3wbDC_H26CQLW3Asyw%40mail.gmail.com.

Re: Recent Entrust Compliance Incidents

[Wayne]

ally-approved/
>>>>> *---*
>>>>> After more than 10 years, short-lived TLS certificates are finally 
>>>>> permitted by the browsers based on CA/Browser Forum ballot SC-063. Gerv 
>>>>> Markham started a short-lived certs discussion in 2014, where he advised 
>>>>> he 
>>>>> was reviewing the 2012 CA/Browser Forum discussion on the topic. He 
>>>>> advised 
>>>>> that short-lived certificates was a plank of the Mozilla revocation 
>>>>> strategy. There was also a paper prepared in 2012 called Towards 
>>>>> Short-Lived Certificates. The paper stated OCSP is as good as dead, so 
>>>>> the 
>>>>> CAs should issue certificates with a very short lifetime. I suppose no 
>>>>> one 
>>>>> thought it would take so much time.
>>>>>
>>>>> Short-lived certificates are designed to help address a certificate 
>>>>> revocation issue. Back in 2012, Adam Langley discussed the seat-belt 
>>>>> issue, 
>>>>> where it works fine, but snaps when you crash. This was based on the fact 
>>>>> the browser implements soft-fail revocation checks where the CRL or OCSP 
>>>>> response is ignored.
>>>>> *---*
>>>>>
>>>>>
>>>>>
>>>>> *6: 2024-03-26: The Path to 90-Day Certificate Validity: Challenges 
>>>>> Facing Organizations*
>>>>>
>>>>> https://www.entrust.com/blog/2024/03/the-path-to-90-day-certificate-validity-challenges-facing-organizations/
>>>>> *---*
>>>>> Certificate lifespan is getting shorter
>>>>>
>>>>> Over the years the cybersecurity industry has undergone notable 
>>>>> transformations requiring organizations to implement new best-practice 
>>>>> standards, often at a short notice.
>>>>>
>>>>> In 2020, Apple unilaterally opted for shorter TLS certificate 
>>>>> durations, reducing them from three years to 398 days, thereby increasing 
>>>>> the burden on certificate management. Subsequently, Apple introduced 
>>>>> shorter lifespans for S/MIME certificates at the start of 2022. In the 
>>>>> past 
>>>>> year, both code signing and S/MIME users faced additional alterations, 
>>>>> while Google proposed transitioning to 90-day certificates, a subject we 
>>>>> have explored in our latest webinar. Anticipating further changes, 
>>>>> particularly with the rise of artificial intelligence (AI) and the 
>>>>> looming 
>>>>> risk of post-quantum (PQ) computing, organizations must enhance their 
>>>>> agility.
>>>>>
>>>>> Today, TLS/SSL certificates are typically valid for about a year, 
>>>>> according to the Certification Authority Browser (CA/B) Forum 
>>>>> requirements. 
>>>>> This yearly renewal cycle is convenient for organizations to manage and 
>>>>> schedule. However, transitioning to shorter-lived certificates, like the 
>>>>> proposed 90-day validity period, will require more frequent renewal 
>>>>> efforts. With 90-day validity, organizations will need to renew 
>>>>> certificates four times every 12 months within that timeframe. In 
>>>>> practice, 
>>>>> due to the need for buffer time, certificates may need to be renewed 
>>>>> every 
>>>>> 60 days. Ultimately, this change could lead to replacing certificates 
>>>>> more 
>>>>> than six times every 12 months, depending on the renewal window chosen.
>>>>> *---*
>>>>>
>>>>> Apologies that some of those got long, I wanted to preserve as much 
>>>>> context as possible given how little material we have to work with.
>>>>>
>>>>> I sincerely ask anyone if they can find any further communication on 
>>>>> these topics by Entrust. Their helpdesk has tutorials on specific 
>>>>> software 
>>>>> setups, but I'm not seeing any actual push for their subscribers to do 
>>>>> anything.
>>>>>
>>>>> It would be very beneficial for Entrust to provide us with any 
>>>>> information on what they've been communicating to their customers to 
>>>>> promote shorter certificate lifespans and automation.
>>>>>
>>>>> - W

Re: Recent Entrust Compliance Incidents

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

 2014, where he advised 
>>>>> he 
>>>>> was reviewing the 2012 CA/Browser Forum discussion on the topic. He 
>>>>> advised 
>>>>> that short-lived certificates was a plank of the Mozilla revocation 
>>>>> strategy. There was also a paper prepared in 2012 called Towards 
>>>>> Short-Lived Certificates. The paper stated OCSP is as good as dead, so 
>>>>> the 
>>>>> CAs should issue certificates with a very short lifetime. I suppose no 
>>>>> one 
>>>>> thought it would take so much time.
>>>>>
>>>>> Short-lived certificates are designed to help address a certificate 
>>>>> revocation issue. Back in 2012, Adam Langley discussed the seat-belt 
>>>>> issue, 
>>>>> where it works fine, but snaps when you crash. This was based on the fact 
>>>>> the browser implements soft-fail revocation checks where the CRL or OCSP 
>>>>> response is ignored.
>>>>> *---*
>>>>>
>>>>>
>>>>>
>>>>> *6: 2024-03-26: The Path to 90-Day Certificate Validity: Challenges 
>>>>> Facing Organizations*
>>>>>
>>>>> https://www.entrust.com/blog/2024/03/the-path-to-90-day-certificate-validity-challenges-facing-organizations/
>>>>> *---*
>>>>> Certificate lifespan is getting shorter
>>>>>
>>>>> Over the years the cybersecurity industry has undergone notable 
>>>>> transformations requiring organizations to implement new best-practice 
>>>>> standards, often at a short notice.
>>>>>
>>>>> In 2020, Apple unilaterally opted for shorter TLS certificate 
>>>>> durations, reducing them from three years to 398 days, thereby increasing 
>>>>> the burden on certificate management. Subsequently, Apple introduced 
>>>>> shorter lifespans for S/MIME certificates at the start of 2022. In the 
>>>>> past 
>>>>> year, both code signing and S/MIME users faced additional alterations, 
>>>>> while Google proposed transitioning to 90-day certificates, a subject we 
>>>>> have explored in our latest webinar. Anticipating further changes, 
>>>>> particularly with the rise of artificial intelligence (AI) and the 
>>>>> looming 
>>>>> risk of post-quantum (PQ) computing, organizations must enhance their 
>>>>> agility.
>>>>>
>>>>> Today, TLS/SSL certificates are typically valid for about a year, 
>>>>> according to the Certification Authority Browser (CA/B) Forum 
>>>>> requirements. 
>>>>> This yearly renewal cycle is convenient for organizations to manage and 
>>>>> schedule. However, transitioning to shorter-lived certificates, like the 
>>>>> proposed 90-day validity period, will require more frequent renewal 
>>>>> efforts. With 90-day validity, organizations will need to renew 
>>>>> certificates four times every 12 months within that timeframe. In 
>>>>> practice, 
>>>>> due to the need for buffer time, certificates may need to be renewed 
>>>>> every 
>>>>> 60 days. Ultimately, this change could lead to replacing certificates 
>>>>> more 
>>>>> than six times every 12 months, depending on the renewal window chosen.
>>>>> *---*
>>>>>
>>>>> Apologies that some of those got long, I wanted to preserve as much 
>>>>> context as possible given how little material we have to work with.
>>>>>
>>>>> I sincerely ask anyone if they can find any further communication on 
>>>>> these topics by Entrust. Their helpdesk has tutorials on specific 
>>>>> software 
>>>>> setups, but I'm not seeing any actual push for their subscribers to do 
>>>>> anything.
>>>>>
>>>>> It would be very beneficial for Entrust to provide us with any 
>>>>> information on what they've been communicating to their customers to 
>>>>> promote shorter certificate lifespans and automation.
>>>>>
>>>>> - Wayne
>>>>>
>>>>> On Saturday, May 11, 2024 at 8:04:24 PM UTC+1 Chris Bailey wrote:
>>>>>
>>>>>> To Ben Wilson and the Mozilla Community:
>>>>>>
>>>>>>  
>>>>>>
>>>>>> I wa

Re: Recent Entrust Compliance Incidents

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

ations to implement new best-practice 
>>> standards, often at a short notice.
>>>
>>> In 2020, Apple unilaterally opted for shorter TLS certificate durations, 
>>> reducing them from three years to 398 days, thereby increasing the burden 
>>> on certificate management. Subsequently, Apple introduced shorter lifespans 
>>> for S/MIME certificates at the start of 2022. In the past year, both code 
>>> signing and S/MIME users faced additional alterations, while Google 
>>> proposed transitioning to 90-day certificates, a subject we have explored 
>>> in our latest webinar. Anticipating further changes, particularly with the 
>>> rise of artificial intelligence (AI) and the looming risk of post-quantum 
>>> (PQ) computing, organizations must enhance their agility.
>>>
>>> Today, TLS/SSL certificates are typically valid for about a year, 
>>> according to the Certification Authority Browser (CA/B) Forum requirements. 
>>> This yearly renewal cycle is convenient for organizations to manage and 
>>> schedule. However, transitioning to shorter-lived certificates, like the 
>>> proposed 90-day validity period, will require more frequent renewal 
>>> efforts. With 90-day validity, organizations will need to renew 
>>> certificates four times every 12 months within that timeframe. In practice, 
>>> due to the need for buffer time, certificates may need to be renewed every 
>>> 60 days. Ultimately, this change could lead to replacing certificates more 
>>> than six times every 12 months, depending on the renewal window chosen.
>>> *---*
>>>
>>> Apologies that some of those got long, I wanted to preserve as much 
>>> context as possible given how little material we have to work with.
>>>
>>> I sincerely ask anyone if they can find any further communication on 
>>> these topics by Entrust. Their helpdesk has tutorials on specific software 
>>> setups, but I'm not seeing any actual push for their subscribers to do 
>>> anything.
>>>
>>> It would be very beneficial for Entrust to provide us with any 
>>> information on what they've been communicating to their customers to 
>>> promote shorter certificate lifespans and automation.
>>>
>>> - Wayne
>>>
>>> On Saturday, May 11, 2024 at 8:04:24 PM UTC+1 Chris Bailey wrote:
>>>
>>>> To Ben Wilson and the Mozilla Community:
>>>>
>>>>  
>>>>
>>>> I want to acknowledge your letter and the input from you and the 
>>>> community. We agree that we have go-forward opportunities to improve.
>>>>
>>>>  
>>>>
>>>> To that end, I want to confirm our intent to provide a full written 
>>>> response to you and the community prior to June 7. Until then, please 
>>>> contact me directly with additional questions or feedback.
>>>>
>>>>  
>>>>
>>>> Sincerely,
>>>>
>>>> Chris Bailey
>>>>
>>>> VP-Digital Certificates
>>>>
>>>> Entrust
>>>>
>>>>  
>>>>
>>>> *From: *'Ben Wilson' via dev-secur...@mozilla.org <
>>>> dev-secur...@mozilla.org>
>>>> *Date: *Tuesday, May 7, 2024 at 10:59 AM
>>>> *To: *dev-secur...@mozilla.org 
>>>> *Subject: *[EXTERNAL] Recent Entrust Compliance Incidents
>>>>
>>>> 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.  
>>>>
>>>> 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 
>>>> <https://urldefense.com/v3/__https:/wiki.mozilla.org/CA/Entrust_Issues__;!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmM8uUFZ84$>.
>>>>  
>>>> 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 
>>>>

Re: Recent Entrust Compliance Incidents

[Wayne]

t; due to the need for buffer time, certificates may need to be renewed every 
>> 60 days. Ultimately, this change could lead to replacing certificates more 
>> than six times every 12 months, depending on the renewal window chosen.
>> *---*
>>
>> Apologies that some of those got long, I wanted to preserve as much 
>> context as possible given how little material we have to work with.
>>
>> I sincerely ask anyone if they can find any further communication on 
>> these topics by Entrust. Their helpdesk has tutorials on specific software 
>> setups, but I'm not seeing any actual push for their subscribers to do 
>> anything.
>>
>> It would be very beneficial for Entrust to provide us with any 
>> information on what they've been communicating to their customers to 
>> promote shorter certificate lifespans and automation.
>>
>> - Wayne
>>
>> On Saturday, May 11, 2024 at 8:04:24 PM UTC+1 Chris Bailey wrote:
>>
>>> To Ben Wilson and the Mozilla Community:
>>>
>>>  
>>>
>>> I want to acknowledge your letter and the input from you and the 
>>> community. We agree that we have go-forward opportunities to improve.
>>>
>>>  
>>>
>>> To that end, I want to confirm our intent to provide a full written 
>>> response to you and the community prior to June 7. Until then, please 
>>> contact me directly with additional questions or feedback.
>>>
>>>  
>>>
>>> Sincerely,
>>>
>>> Chris Bailey
>>>
>>> VP-Digital Certificates
>>>
>>> Entrust
>>>
>>>  
>>>
>>> *From: *'Ben Wilson' via dev-secur...@mozilla.org <
>>> dev-secur...@mozilla.org>
>>> *Date: *Tuesday, May 7, 2024 at 10:59 AM
>>> *To: *dev-secur...@mozilla.org 
>>> *Subject: *[EXTERNAL] Recent Entrust Compliance Incidents
>>>
>>> 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.  
>>>
>>> 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 
>>> <https://urldefense.com/v3/__https:/wiki.mozilla.org/CA/Entrust_Issues__;!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmM8uUFZ84$>.
>>>  
>>> 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 
>>> <https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1651481__;!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMYStPTzU$>
>>>  
>>> and #1648472 
>>> <https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1648472__;!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMQsOKu7I$>),
>>>  
>>> 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 
>>> <https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1651481*c17__;Iw!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMgQVGatQ$>
>>>  
>>> in those bugs to address the root problems through process improvements, 
>>> and it is concerning to see so little improvement 4 years la

Re: Recent Entrust Compliance Incidents

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

 flow correctly. Without automation, this could be more challenging.
>
> For example, if you implement automation for your TLS certificates, this 
> means that you need to have a credential for your certificate authority. 
> You need to also have a credential, for example, for your domain name 
> provider, your DNS system. And that's all needed to prove domain control 
> and to make sure that a certificate with the right identity is issued for 
> your endpoints.
>
> But what if these credentials get compromised? Look at the DNS system.
> *---*
>
>
>
> *5: 2023-08-14: Short-lived Certificates finally approved*
>
> https://www.entrust.com/blog/2023/08/short-lived-certificates-finally-approved/
> *---*
> After more than 10 years, short-lived TLS certificates are finally 
> permitted by the browsers based on CA/Browser Forum ballot SC-063. Gerv 
> Markham started a short-lived certs discussion in 2014, where he advised he 
> was reviewing the 2012 CA/Browser Forum discussion on the topic. He advised 
> that short-lived certificates was a plank of the Mozilla revocation 
> strategy. There was also a paper prepared in 2012 called Towards 
> Short-Lived Certificates. The paper stated OCSP is as good as dead, so the 
> CAs should issue certificates with a very short lifetime. I suppose no one 
> thought it would take so much time.
>
> Short-lived certificates are designed to help address a certificate 
> revocation issue. Back in 2012, Adam Langley discussed the seat-belt issue, 
> where it works fine, but snaps when you crash. This was based on the fact 
> the browser implements soft-fail revocation checks where the CRL or OCSP 
> response is ignored.
> *---*
>
>
>
> *6: 2024-03-26: The Path to 90-Day Certificate Validity: Challenges Facing 
> Organizations*
>
> https://www.entrust.com/blog/2024/03/the-path-to-90-day-certificate-validity-challenges-facing-organizations/
> *---*
> Certificate lifespan is getting shorter
>
> Over the years the cybersecurity industry has undergone notable 
> transformations requiring organizations to implement new best-practice 
> standards, often at a short notice.
>
> In 2020, Apple unilaterally opted for shorter TLS certificate durations, 
> reducing them from three years to 398 days, thereby increasing the burden 
> on certificate management. Subsequently, Apple introduced shorter lifespans 
> for S/MIME certificates at the start of 2022. In the past year, both code 
> signing and S/MIME users faced additional alterations, while Google 
> proposed transitioning to 90-day certificates, a subject we have explored 
> in our latest webinar. Anticipating further changes, particularly with the 
> rise of artificial intelligence (AI) and the looming risk of post-quantum 
> (PQ) computing, organizations must enhance their agility.
>
> Today, TLS/SSL certificates are typically valid for about a year, 
> according to the Certification Authority Browser (CA/B) Forum requirements. 
> This yearly renewal cycle is convenient for organizations to manage and 
> schedule. However, transitioning to shorter-lived certificates, like the 
> proposed 90-day validity period, will require more frequent renewal 
> efforts. With 90-day validity, organizations will need to renew 
> certificates four times every 12 months within that timeframe. In practice, 
> due to the need for buffer time, certificates may need to be renewed every 
> 60 days. Ultimately, this change could lead to replacing certificates more 
> than six times every 12 months, depending on the renewal window chosen.
> *---*
>
> Apologies that some of those got long, I wanted to preserve as much 
> context as possible given how little material we have to work with.
>
> I sincerely ask anyone if they can find any further communication on these 
> topics by Entrust. Their helpdesk has tutorials on specific software 
> setups, but I'm not seeing any actual push for their subscribers to do 
> anything.
>
> It would be very beneficial for Entrust to provide us with any information 
> on what they've been communicating to their customers to promote shorter 
> certificate lifespans and automation.
>
> - Wayne
>
> On Saturday, May 11, 2024 at 8:04:24 PM UTC+1 Chris Bailey wrote:
>
>> To Ben Wilson and the Mozilla Community:
>>
>>  
>>
>> I want to acknowledge your letter and the input from you and the 
>> community. We agree that we have go-forward opportunities to improve.
>>
>>  
>>
>> To that end, I want to confirm our intent to provide a full written 
>> response to you and the community prior to June 7. Until then, please 
>> contact me directly with additional questions or feedback.
>>
>>  
>>
>&g

Re: Recent Entrust Compliance Incidents

[Wayne]

 intelligence (AI) and the looming risk of post-quantum 
(PQ) computing, organizations must enhance their agility.

Today, TLS/SSL certificates are typically valid for about a year, according 
to the Certification Authority Browser (CA/B) Forum requirements. This 
yearly renewal cycle is convenient for organizations to manage and 
schedule. However, transitioning to shorter-lived certificates, like the 
proposed 90-day validity period, will require more frequent renewal 
efforts. With 90-day validity, organizations will need to renew 
certificates four times every 12 months within that timeframe. In practice, 
due to the need for buffer time, certificates may need to be renewed every 
60 days. Ultimately, this change could lead to replacing certificates more 
than six times every 12 months, depending on the renewal window chosen.
*---*

Apologies that some of those got long, I wanted to preserve as much context 
as possible given how little material we have to work with.

I sincerely ask anyone if they can find any further communication on these 
topics by Entrust. Their helpdesk has tutorials on specific software 
setups, but I'm not seeing any actual push for their subscribers to do 
anything.

It would be very beneficial for Entrust to provide us with any information 
on what they've been communicating to their customers to promote shorter 
certificate lifespans and automation.

- Wayne

On Saturday, May 11, 2024 at 8:04:24 PM UTC+1 Chris Bailey wrote:

> To Ben Wilson and the Mozilla Community:
>
>  
>
> I want to acknowledge your letter and the input from you and the 
> community. We agree that we have go-forward opportunities to improve.
>
>  
>
> To that end, I want to confirm our intent to provide a full written 
> response to you and the community prior to June 7. Until then, please 
> contact me directly with additional questions or feedback.
>
>  
>
> Sincerely,
>
> Chris Bailey
>
> VP-Digital Certificates
>
> Entrust
>
>  
>
> *From: *'Ben Wilson' via dev-secur...@mozilla.org <
> dev-secur...@mozilla.org>
> *Date: *Tuesday, May 7, 2024 at 10:59 AM
> *To: *dev-secur...@mozilla.org 
> *Subject: *[EXTERNAL] Recent Entrust Compliance Incidents
>
> 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.  
>
> 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 
> <https://urldefense.com/v3/__https:/wiki.mozilla.org/CA/Entrust_Issues__;!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmM8uUFZ84$>.
>  
> 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 
> <https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1651481__;!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMYStPTzU$>
>  
> and #1648472 
> <https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1648472__;!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMQsOKu7I$>),
>  
> 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 
> <https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1651481*c17__;Iw!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMgQVGatQ$>
>  
> 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 repor

Re: [EXTERNAL] Recent Entrust Compliance Incidents

['Chris Bailey' via dev-security-policy@mozilla.org]

To Ben Wilson and the Mozilla Community:

I want to acknowledge your letter and the input from you and the community. We 
agree that we have go-forward opportunities to improve.

To that end, I want to confirm our intent to provide a full written response to 
you and the community prior to June 7. Until then, please contact me directly 
with additional questions or feedback.

Sincerely,
Chris Bailey
VP-Digital Certificates
Entrust

From: 'Ben Wilson' via dev-security-policy@mozilla.org 

Date: Tuesday, May 7, 2024 at 10:59 AM
To: dev-secur...@mozilla.org 
Subject: [EXTERNAL] Recent Entrust Compliance Incidents
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. 


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<https://urldefense.com/v3/__https:/wiki.mozilla.org/CA/Entrust_Issues__;!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmM8uUFZ84$>.
 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<https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1651481__;!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMYStPTzU$>
 and 
#1648472<https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1648472__;!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMQsOKu7I$>),
 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<https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1651481*c17__;Iw!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMgQVGatQ$>
 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<https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1651481*c17__;Iw!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMgQVGatQ$>
 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<https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1886532*c0__;Iw!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF

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
>  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
> things go wrong, so that we can effectively collaborate on identifying
> solutions to avoid that going forward.”
>
> *Late Revocation due to SHA-256 hash algorithm - *
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1651481
>
> This bug is related to Bug #1648472. Entrust issued TLS certificates

Re: Recent Entrust Compliance Incidents

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

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 
> things go wrong, so that we can effectively collaborate on identifying 
> solutions to avoid that going forward.”
>
> Late Revocation due to SHA-256 hash algorithm -
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1651481
>
> This bug is related to Bug #1648472.Entrust issued TLS certificates using ECC 
> P-384 keys hashed with SHA-256, contrary to Mozilla policy requiring SHA-384 
> for hashing. Entrust’s initial decision was to allow 

Re: Recent Entrust Compliance Incidents

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

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
things go wrong, so that we can effectively collaborate on identifying
solutions to avoid that going forward.”

*Late Revocation due to SHA-256 hash algorithm - *

https://bugzilla.mozilla.org/show_bug.cgi?id=1651481

This bug is related to Bug #1648472.  Entrust issued TLS certificates using
ECC P-384 keys hashed with SHA-256, contrary to Mozilla policy requiring
SHA-384 for hashing. Entrust’s initial decision was to allow certificates
to expire naturally without revocation, but this was revised with a
decision to revoke all affected certificates. Entrust committed to: filing
incident report within one business day for future incidents, filing late
revocation incident reports within the required 24 hours or 5 days, as
applicable, and advising Subscribers about revocation within 24 hours or 5
days, or provide an explanation if they are unable to meet such timeframes.
Entrust was told it needed to align its revocation procedures more closely
with the Baseline Requirements and Mozilla’s policy, especially in
providing a detailed rationale for any delays in revocation on a
per-subscriber basis and ensuring timely revocation in line with the
Baseline Requirements.



On Thu, May 9, 2024 at 8:13 

Re: Recent Entrust Compliance Incidents

[Watson Ladd]

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



-- 
Astra mortemque praestare gradatim

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

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.