All I can say is... wow. This report seems to treat the recent issues at Entrust as a compliance matter, rather than a matter of trust. Which says it all really.
I find particularly galling the very clear commitment <https://bugzilla.mozilla.org/show_bug.cgi?id=1651481#c6> Entrust made in 2020 to not have any more delayed or failed revocations, and yet here we are in 2024 with a whole slew of them. But rather than then go on to echo the other criticisms, I would like to bring another observation: Entrust seems to have completely missed the boat with bug #1890898 <https://bugzilla.mozilla.org/show_bug.cgi?id=1890898>. Even if their revised analysis -- that revocation was not required -- is correct (and I am not a sufficient expert to know), it does not change the fact that for 2 months Entrust believed the certificates were misissued and chose not to revoke for those two months. Which shows blatant disregard for the requirements of the BRs. Especially since this bug then doesn't even make an appearance in section 2.5.1 of this report. I think Jeffrey Walton hit the nail on the head: "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." I would go further and suggest that all root programs should look to distrust the Entrust roots (for both TLS and S/MIME purposes) by end of 2024. I just don't see how Entrust, with current management, can plausibly be believed to have any road back to trust. Tyrel On Friday, June 7, 2024 at 3:53:10 PM UTC-4 Bruce Morton wrote: > Please respond to comments you may have on our report or action items > here. We will track our progress against the action items list in Bugzilla > under bug 1901270. > > On Friday, June 7, 2024 at 12:51:48 PM UTC-4 Ben Wilson wrote: > >> All, >> I have created Bugzilla Bug#1901270 >> <https://bugzilla.mozilla.org/show_bug.cgi?id=1901270> as an Entrust >> "meta" bug for gathering all action items that will be included in their >> report. >> Please don't comment yet in that bug until Entrust has submitted its >> report and populated the Bugzilla bug with their action items. >> Thanks, >> Ben >> >> On Friday, June 7, 2024 at 4:41:03 AM UTC-6 [email protected] wrote: >> >>> As an advanced warning to Entrust on supplying the report please keep in >>> mind that MDSP has a moderation queue for new members. If the report is to >>> be sent to the mailing list today, then please make sure to use an account >>> that has been pre-approved, or otherwise submit it early enough that a >>> moderator can approve it to arrive on-time. >>> >>> On Wednesday, May 15, 2024 at 4:06:49 PM UTC+1 Amir Omidi (aaomidi) >>> wrote: >>> >>>> I wanted to also add that I'd like Entrust to address why they don't >>>> stop certificate issuances when they find out they're misissuing >>>> certificates? >>>> >>>> As part of my series on Entrust >>>> <https://webpki.substack.com/t/entrust-considered-harmful>. In Part 2 >>>> <https://webpki.substack.com/p/entrust-considered-harmful-part-2> I >>>> found a concerning issue from Entrust that went unnoticed at the time, >>>> which shows a pattern of gross-negligence when it comes to incident >>>> response: Entrust: SHA-256 hash algorithm used with ECC P-384 key >>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1648472> >>>> >>>> In this incident, Entrust discovers that they're misissuing >>>> certificates on 2020-06-17. Despite finding out about this incident, they >>>> continue to misissue certificates all the way till 2020-06-24: >>>> https://crt.sh/?id=2998515551&opt=zlint >>>> >>>> There have been a couple of examples of Entrust making this decision in >>>> the past, such as: Entrust: Printable String Constraint Failure >>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1635096>. Similar to the >>>> previous incident, they did not disable issuance on their systems that was >>>> capable of misissuing certificates (emphasis mine): >>>> > Whether your CA has stopped, or has not yet stopped, issuing >>>> certificates with the problem. A statement that you have will be >>>> considered >>>> a pledge to the community; a statement that you have not requires an >>>> explanation. >>>> >>>> The CA software has a bug which encodes quotation marks in the >>>> organization field using PrintableString instead of UTF8String. *This >>>> software has not been fixed at this time.* >>>> >>>> And more recently, we saw this behavior in the start of this saga: >>>> Entrust: >>>> EV TLS Certificate cPSuri missing >>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1883843#c4> >>>> >>>> On Saturday, May 11, 2024 at 6:37:52 PM UTC-4 Wayne wrote: >>>> >>>>> I can't speak for everyone but in an issue of public trust asking for >>>>> private feedback and concerns is not helping matters. >>>>> >>>>> One of the prevalent topics that have came up in these issues is >>>>> shorter certificate lifespans, certificate automation and how Entrust are >>>>> working very hard with their customers. I'm very curious if Entrust can >>>>> quantify this in any way? >>>>> >>>>> Taking a step back and just looking at their public statements >>>>> regarding lifespans, automation and ACME should give us an idea of their >>>>> internal viewpoint and how this topic is presented to customers. Outside >>>>> of >>>>> the first issue I won't be quoting bugzilla, it's there solely to provide >>>>> context as I can't see an earlier point that automation was promised. >>>>> >>>>> Let's dive in, sources all provided if there are any questions about >>>>> the rough transcript or context. >>>>> >>>>> *1: 2023-03-27: Entrust: Delayed Revocation for EV TLS Certificate >>>>> incorrect jurisdiction* >>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1804753#c8 >>>>> *---* >>>>> Late revocations are base primarily by Subscribers which have not >>>>> implemented automation. We have increased our efforts to extend >>>>> implementation of ACME. We are also considering implementing the ACME >>>>> Renewal Information (ARI) Extension, which allow the certificate to be >>>>> automatically renewed before the revocation date. >>>>> >>>>> In the shorter term, we will provide Subscribers with automated >>>>> reminders on the revocation date for miss-issued certificates. We will >>>>> plan >>>>> to allow short extensions, based on the severity of the miss-issuance. >>>>> *---* >>>>> >>>>> >>>>> >>>>> *2: 2023-04-21: Google’s 90 day proposal for TLS certificates* >>>>> >>>>> https://www.entrust.com/blog/2023/04/googles-90-day-proposal-for-tls-certificates/ >>>>> *---* >>>>> Even if CAs and other browsers don’t share Google’s objectives, there >>>>> is a chance that Google could unilaterally make this change in its root >>>>> program and force the entire industry in this direction in a time of >>>>> their >>>>> choosing. We hope that browsers will not make this decision unilaterally, >>>>> but instead allow the decision to be made with broad industry and website >>>>> owner consensus. >>>>> >>>>> Another issue is that Google has presented no public research or >>>>> factual data showing that such a change to the ecosystem is necessary or >>>>> useful in many use cases. We believe there will be much discussion before >>>>> a >>>>> 90-day ballot will pass at the CABF as several CAs have indicated that a >>>>> requirement for 90-day certificates might have far-reaching implications. >>>>> There have also been several EU governmental bodies concerned over the >>>>> market and competitive implications of Google’s proposal and the impact >>>>> on >>>>> eIDAS Qualified Website Authentication Certificate objectives, which are >>>>> now being reasserted in the EU’s update of its eIDAS legislation. >>>>> >>>>> Entrust does not believe that a maximum 90-day limit for TLS >>>>> certificate lifetimes is the only method to drive automation and the >>>>> deployment of ACME. Additionally, Entrust doesn’t believe that ACME is >>>>> the >>>>> only method for automation, or that it would be accepted by some of the >>>>> most complex subscriber secure server deployments. Rather, we believe >>>>> subscribers should be encouraged to deploy automation, but do not need to >>>>> be discouraged by the cost and complexity of certificates with 90-day >>>>> maximum validity. >>>>> >>>>> While Entrust is not currently in favor of a mandatory 90-day >>>>> certificate limit, we have no objection to 90-day certificates if that is >>>>> what a website wants to use. We are always working to improve or extend >>>>> its >>>>> validation, issuance, and management processes, including greater use of >>>>> automation through integrations with certificate lifecycle management >>>>> (CLM) >>>>> solutions such as Entrust Certificate Hub, AppViewX, Venafi, and >>>>> ServiceNow, as well as automation through ACME v2, CMP, SCEP, and other >>>>> new >>>>> methods. >>>>> >>>>> We understand that this Google proposal may be causing our customers >>>>> considerable concern. In accordance with Google’s instructions on its >>>>> Chrome Root Program Policy, we encourage customers to direct any >>>>> questions >>>>> or input regarding the Google proposal to [email protected]; >>>>> please feel free to share a copy with us at [email protected]. >>>>> *---* >>>>> >>>>> >>>>> >>>>> *3: 2023-07-26: Entrust Cybersecurity Institute Explains: 90-day >>>>> TLS/SSL Certificate Lifecycle* >>>>> https://www.youtube.com/watch?v=GcKunPD5SRw >>>>> *---* >>>>> 0:41-1:48 >>>>> Today we're using certificates that are generally valid for about a >>>>> year. Technically, according to the requirements, we can go to 398 days >>>>> to >>>>> give you a bit of room so that you can have one day of the year at which >>>>> you renew your certificates. That is something that is easy to remember, >>>>> scheduling your agenda as a yearly renewal of those certificates when >>>>> they >>>>> need to happen. >>>>> >>>>> When they're moving to shorter-lived certificates, such as the >>>>> proposed 90 days, this means that you need to do this now four times a >>>>> year >>>>> in a window of 90 days. >>>>> >>>>> Moving to 90-day certificates means that you're practically going to >>>>> renew your certificates probably every 60 days. Meaning that in the end, >>>>> you have to replace your certificates four to six times a year, depending >>>>> on what window you allow to renew that certificate. >>>>> >>>>> 90-day certificates will have a few benefits. So one is that they will >>>>> drive automation. >>>>> >>>>> >>>>> 2:51-3:30 >>>>> That doesn't [mean to] say that there's no problems and that 90-day >>>>> certificates are actually going to solve this. Crypto agility is >>>>> important, >>>>> but that means more than just automating your certificate lifecycle. >>>>> >>>>> For example, if the CA would give you an indication through the >>>>> automated system that your certificate must be replaced, how does >>>>> currently >>>>> the CA know that your system is capable of running a certain algorithm? >>>>> Have you updated your libraries? >>>>> >>>>> So we still have a long step ahead of us really to make that crypto >>>>> agility a reality. >>>>> >>>>> 4:41-end >>>>> >>>>> We're working with the Internet Engineering Task Force, where >>>>> Anthos(?) created a proposal for a sort of auto-discovery based on the >>>>> most >>>>> used automation, the ACME Auto Certificate Management Environment. >>>>> >>>>> And that would help our customers actually to simplify this mechanism >>>>> of renewing certificates in different platforms with different systems, >>>>> without having to reconfigure every individual system to work with the >>>>> certificate authority and the type of certificates they're dealing with. >>>>> Together with[sic] very important is one of the risks of automation, is >>>>> that you're not doing it as a human. >>>>> >>>>> If you do a process, if you follow a step-by-step process that is >>>>> defined and tested, then you know the outcome, because you're following >>>>> the >>>>> steps. But in automation, something might go wrong. And how do you know? >>>>> You need to make sure that systems are notifying you as someone is >>>>> watching >>>>> the notifications. >>>>> >>>>> That's also why in this similar proposal, we've included the mechanism >>>>> of backup configuration. So if one process would fail, there is another >>>>> process that can be followed. But other things are still in development. >>>>> And we will see how that turns out. But the ecosystem seems to be >>>>> supporting it. >>>>> *---* >>>>> >>>>> >>>>> >>>>> *4: 2023-07-26: Entrust Cybersecurity Institute Explains: Zero Trust >>>>> and TLS/SSL Certificate Management* >>>>> https://www.youtube.com/watch?v=nd0QCvu2F_E >>>>> *---* >>>>> 1:20-2:18 >>>>> >>>>> Well, first I would say we need to adopt automation. But then at the >>>>> same point, I would point them at the risk of automation. Where processes >>>>> by humans are easily manageable and can have multiple steps to ensure >>>>> they >>>>> 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. >>>>>> >>>>>> >>>>>> >>>>>> Sincerely, >>>>>> >>>>>> Chris Bailey >>>>>> >>>>>> VP-Digital Certificates >>>>>> >>>>>> Entrust >>>>>> >>>>>> >>>>>> >>>>>> *From: *'Ben Wilson' via [email protected] < >>>>>> [email protected]> >>>>>> *Date: *Tuesday, May 7, 2024 at 10:59 AM >>>>>> *To: *[email protected] <[email protected]> >>>>>> *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_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmM8gYsLCM$> >>>>>> >>>>>> 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 "[email protected]" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> 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 >>>>>> >>>>>> <https://urldefense.com/v3/__https:/groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA*2B1gtaYURqFzRqVmJdc7fBXE1mbGs25HpSkp5wZ0Xm*2BRG0YHCA*40mail.gmail.com?utm_medium=email&utm_source=footer__;JSUl!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmM525_4vY$> >>>>>> . >>>>>> *Any email and files/attachments transmitted with it are intended >>>>>> solely for the use of the individual or entity to whom they are >>>>>> addressed. >>>>>> If this message has been sent to you in error, you must not copy, >>>>>> distribute or disclose of the information it contains. Please notify >>>>>> Entrust immediately and delete the message from your system.* >>>>>> >>>>> -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/11d7f539-29b8-463b-90a0-5efe59912687n%40mozilla.org.
