Re: Recent Entrust Compliance Incidents

2024-05-15 Thread '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

2024-05-11 Thread 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

2024-05-11 Thread '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

2024-05-10 Thread '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

2024-05-10 Thread '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

2024-05-10 Thread '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

2024-05-09 Thread 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

2024-05-07 Thread '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.