Entrust considered harmful - Part 2
Where Entrust chooses to continue misissuing certificates
This piece is Part 2 of a series on Entrust’s historically harmful behavior as a CA. If you haven’t read Part 1 yet, you can find the link here.
Similar to Part 1, I’m using a SIRQ (Subjective Incident Response Quality) to assign some subject score to each of these incidents.
Entrust made a decision to knowingly continue the misissuance of certificates in “Entrust: EV TLS Certificate cPSuri missing.” I’ve been unable to understand what led them to make this decision. It was obvious to anyone who has been in the WebPKI ecosystem that a choice like that would have negative consequences for the CA. I did try to ask Entrust to explain their decision-making process about how and why they decided to do that. Unfortunately, I was unable to get a clear answer from them about this.
In this post, I find that Entrust has made that same decision in the past. Unfortunately, back then it went unnoticed.
Entrust: EV Certificates Issued with Business Category "Non-Commercial" when it should have been set to "Private Organization"
2019-11-25
In this incident, Entrust issues a certificate to a private organization but mistakingly marks it as a “Non-Commercial Entity” in the subject information. Entrust does not find this problem on their own, and it is reported to them in a CPR.
The interesting thing with “Non-Commercial Entity”, as Ryan Sleevi also points it out, is that it has a very, very narrow circumstance where a business would fall under that category. Specifically, under the EVGs at the time:
An Applicant qualifies as a Non-Commercial Entity if:
(A) The Applicant is an International Organization Entity, created under a charter, treaty, convention or equivalent instrument that was signed by, or on behalf of, more than one country's government. The CA/Browser Forum may publish a listing of Applicants who qualify as an International Organization for EV eligibility; and
(B) The Applicant is not headquartered in any country where the CA is prohibited from doing business or issuing a certificate by the laws of the CA's jurisdiction; and
(C) The Applicant is not listed on any government denial list or prohibited list (e.g., trade embargo) under the laws of the CA's jurisdiction.
Very few organizations are going to meet this definition, so it was concerning that this option was so easily mistaken by Entrust validators.
In response to this, Entrust keeps trying to push this off as a one-off human error. However, Ryan Sleevi keeps expecting them to look at this more holistically:
Put differently: Looking at existing organizations, rather than the businessCategory selection, seems to be learning the wrong lesson; it would seem like every Non-Commercial Entity validation should be treated as high risk, rather than previously encountered organizations. And if that's done, it shouldn't matter if it's a previous organization or not. It similarly doesn't seem to make sense to look at the previous organizations and treat them as high risk if, for example, they're applying as a private organization.
…
I mention this, because it seems the replies are focused on this specific issue (and perhaps because it's the immediate issue), but it's not clear much is being done to systemically understand. A systemic approach would look at not just where "non-commercial entities" failed, nor would it explore "just" the businessCategory field, but it would look for all places that human judgement is being made by teams, and look to see if there are ways to remove or reduce the humans in the loop, or provide them tools to support their efforts. While NCEs might be solvable by an allowlist, figuring out the distinction for things like Government Entities is also important. Examining Entrust's use of the businessCategory field as a whole, making sure all things are consistent. Going beyond that, looking through data sources they use and understanding what the validation process actually looks like, and not just what folks are trained to do.
In response to this, Entrust agrees to switch the issuance for Non-Commercial Entities into an allow-list model. Not understanding that they really ought to go beyond just this one field.
Beyond the immediate incident here, Entrust said something very troubling that unfortunately was not highlighted at the time:
We do regularly monitor other CA issues in the Google discussion group -https://groups.google.com/forum/#!forum/mozilla.dev.security.policy
We do monitor the CA issues with Mozilla/Bugzilla but we primarily use the Google discussion group to monitor CA issues due to the volume of bugs that are posted in Bugzilla that are not always related to CA practices.
I’m extremely surprised that Entrust doesn’t know you can filter by categories on Bugzilla. Here is a simple search to find all the incidents Entrust has had. And here is another search that looks across all CAs. Bugzilla goes as far as offering an easy-to-use REST API to build automation around these searches.
SIRQ: 3
Entrust: Compromised Private Key was not Revoked in Less than 24 Hours
2020-01-23
This was one of the higher-quality incident reports from Entrust. Netgear had put a publicly trusted, valid certificate alongside its key inside firmware shipped to customers. External parties reported this as a Certificate Problem Report to Entrust. The first report wasn’t classified properly. This led to the revocation going a few hours beyond the 24-hour time limit imposed by the BRs.
The action items Entrust placed here, which was to scan emails for specific “keywords” seemed reasonable. Ryan Sleevi did recommend creating a different email address for compliance-related issues. However, I don’t think that would’ve helped here. Unfortunately, these email endpoints remain a strong target for spam. It’s something that I had to deal with at Google Trust Services, and we ended up with a Google Form-based solution. It’s still not perfect, but it did significantly cut down on our spam.
Overall, this was a strong incident response from Entrust.
SIRQ: 5
Entrust: S/MIME Certificate Issued with Incorrect Policy OID
2020-04-03
In this incident, Entrust misissues a certificate with a wrong policy OID for S/MIME certificates back in… 2019-05-13. This problem wasn’t discovered in the QA system and was then found in the production system leading to 6 misissued certificates.
Entrust then had to have their auditors point out on 2020-03-31, that these were misissuances, and had to be both reported to Bugzilla and revoked.
13 May 2019, UTC 20:19 to 21:28 - Six (6) S/MIME certificates were issued to the Entrust QA team with the incorrect certificate policy extension OID.
13 May 2019, 21:56 UTC - It was discovered using post issuance linting software that the certificate policy extension OID was incorrect.
14 May 2019, 11:52 UTC - It was confirmed that the certificate policy extension OID had been corrected.
31 March 2020, 18:00 UTC - Deloitte advised as part of their annual compliance audit that 6 S/MIME certificates were issued with the incorrect certificate policy extension OID.
This is a very concerning incident because it showcases a couple of systemic problems in Entrust’s QA and compliance model:
First, somehow, the post-issuance linting in the QA system was not able to pick these up. However, the post-issuance linting in the production system did. What is the point of a QA system, if it’s not connected up to the same linting machinery. The entire reason you have a QA system is to effectively run your issuance process through the same system but with a non-publicly-trusted key.
They address this one as an “action item” (but it can’t really be called that since action items need due dates.):
Second, Entrust knew these were misissued since the linting software did tell them that. They went ahead and fixed the bug, but never filed an incident for it. They also didn’t revoke these certs, until their auditor told them they need to.
Entrust either keeps misreading and misunderstanding, or just outright doesn’t care enough about the rules and regulations here to really nail in the message that “misissued certificates are an incident, and need to be reported.”
Furthermore, in this incident, Ryan Sleevi points out that this OID problem is a symptom of something else. And that the action items for this incident are simply not there.
In short, I see the "mismatched OID" as a symptom, and the concern here I'm trying to get at is that there were one or more misissued certificates that were not disclosed here as CA incidents. The proposed remediation in Comment #1 doesn't seem to capture that these should have been disclosed as a CA Incident when they were detected, separate and independent from their revocation and remediation. Your description in Comment #3 focuses on detection during QA, which is good, but I think it's overlooking the lack of report as another problem to be remediated. Comment #1 notably lacks "disclosed to Mozilla" as part of the external CPR steps, so that's somewhat telling in its omission.
Unfortunately, this bug is closed without any action items (that have deadlines) to prevent these problems in the future.
SIRQ: 0
Entrust: Printable String Constraint Failure
2020-05-04
In this incident, Entrust issued a certificate with a `"` in the OrganizationName for the Subject:
AMBODIA ASIA BANK LIMITED "CAB"Looking at the ASN.1 of the impacted certificate, we see that the OrganizationName was encoded with PrintableString (hex code of 13). However, under the ASN.1 rules, PrintableString can not contain a quote.1
In this incident, Entrust states that the certificate was able to pass pre-issuance linting, but failed on post-issuance linting:
This error was unknown as quotation marks are not a character that is typically used in the Organization field. The certificate information did pass through pre-issuance linting using zlint without error. The certificate was post-issuance linted using cablint where the error was found.
It looks like zlint currently detects this error:
https://crt.sh/?id=2746128448&opt=zlint
How did zlint not detect it when run pre-issuance?
Thanks for the comments. In investigating this issue while working on the upgrade to the latest zlint version, we finally realized why this error got past our inline linter but not our post-issuance checker. The ASN.1 parse error causes zlint to abort very early on, and this error return from zlint doesn’t get processed in our inline linting code the same way as other linter alarms. We are fixing our inline integration with zlint to recognize this scenario and report an error rather than reporting that nothing’s wrong and leave it to the post-issuance checker to catch.
Once again a long delay between incident discovery and remediation.
Side note: I do not understand why some CAs have this very weird setup for linting their certs, both pre and post-issuance. I promise to write more about linting, what it can and can’t do, and how to properly integrate with it.
Thanks to this incident, this was highlighted a little bit more carefully in the Entrust README: https://github.com/zmap/zlint/pull/460
Beyond the immediate incident, Entrust struggled to revoke this certificate through its OCSP system. They were finally able to revoke this certificate on their OCSP responders on 2020-05-29.
I’m not that surprised, but still disappointed that Entrust took months to actually root cause why their zlint was behaving differently from the one on crt.sh.
Worst part of this incident? Entrust made the decision to keep their systems, that had this bug on them, active and issuing certificates. Even though it could be producing misissued certificates depending on user input. Furthermore, Entrust could not OCSP revoke these misissued certificates:
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.
Not to get ahead of ourselves here, but we’ve seen this behavior very recently as well: https://bugzilla.mozilla.org/show_bug.cgi?id=1883843#c4
The failure to revoke led to the next incident.
SIRQ: -1
Entrust: Failure to revoke a certificate
2020-05-07
This incident is a continuation of the one above it. This incident was initially opened by Ryan Sleevi. Entrust took over 20 days (2020-05-29) to provide the full incident report for this incident.
Julien Cristau from Mozilla responds to their incident response, (2020-06-01) pointing out that their incident response is lacking the timeline of the action items mentioned in the incident report. Entrust, once again, takes another long delay of 16 days (2020-06-17) to respond:
The subordinate CA was migrated to the new software on 9 June 2020, which has resolved the printable string bug with this CA. This software is being migrated to all subordinate CAs which can issue SSL certificates.
The thing is, this is irrelevant to this bug. The action items on a failure to revoke bug are solely to be about what your CA will do to prevent a failure to revoke in the future. Entrust finally answers that:
The certificate was revoked within the 5 day per CRL. However, the new OCSP system rejected the certificate as it was incorrect per incident https://bugzilla.mozilla.org/show_bug.cgi?id=1636339, so there was no revoked OCSP response. In addition, to prevent an attack of false certificate status, the OCSP system would not allow a certificate serial number to be uploaded. The OCSP system was patched to allow a certificate serial number to be uploaded, but only in a revoked status.
The CA has been migrated, which will prevent the same error in the future. The OCSP system has been upgraded to allow a rejected certificate to be uploaded as revoked.
Entrust claims that they finally have the system to revoke OCSP by serial number in place. Something that should’ve been there to begin with.
SIRQ: -1
Entrust: SHA-256 hash algorithm used with ECC P-384 key
2020-06-25
Some background here, Mozilla policy requires a CA to use SHA-256 if the signing key is using P-256 curves, and SHA-384 when P-384 curves are used.
On 2020-06-17, Entrust discovers that they are issuing certificates with a mismatched hashing algorithm for their key type.
In response to “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.” Entrust provides a non-answer:
On 19 May 2020, L1F has been migrated to new CA software which hashes using SHA-384.
On 24 June 2020, L1J has been migrated to new CA software which hashes using SHA-384.
They avoid using the word “yes” or “no”.
So, the question is, after Entrust figured out that they were misissuing certificates on the 17th, did they stop issuance before starting their work on repairing the CA?
The answer is: No. No, they did not. Entrust issued this certificate on 2020-06-24. This certificate was issued a week after they found out that they were misissuing certificates. Note: This misissuance was for the “U.S. Securities and Exchange Commission”.
Beyond the negligence seen here, they then go on to make this statement in their incident response:
Although the certificates have not been issued in accordance with Mozilla Policy, we are not planning to revoke these certificates. ECDSA P-384 with SHA-256 provides 128-bit security strength, which is the same security level as P-256 with SHA-256, which is allowed by the Mozilla Root Store Policy v2.7. However, some Subscribers may have thought that they were receiving 192-bit security strength since the key is P-384. As such, we will advise Subscribers of the issue and will offer certificate re-issue at no cost.
Once again, Entrust somehow did a risk and security analysis within days. While failing to do a proper root-cause analysis.
Side note: I also love how they’re gloating that they’re going to replace these free of charge. These are certs that should be revoked to begin with.
Ryan Sleevi responds to the incident report with the following questions:
A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.
17 June 2020: Issue discovered using crt.sh linting software. The problem occurs with two ECC SSL subordinate CA, which are referred to as L1F and L1J.
There's a significant lack of detail regarding the previous events, including the non-compliance found at other CAs, and which was discussed at Entrust.
Should we conclude, based on this timeline, that Entrust Datacard has been actively ignoring Mozilla changes, and ignoring discussion in mozilla.dev.security.policy? If that's not the case, could you please update this timeline to provide a more detailed picture of the discussions followed and steps taken?
Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
The CAs were put into production in April 2016, which was before Mozilla changed their policy. It was understood that the CAs must using a version of SHA-2, and SHA-256 was chosen. When Mozilla Policy 2.4 was introduced, it was not observed that these CAs were not configured correctly.
This isn't an explanation of how and why the mistakes were made, and how they avoided detection until now. This is simply a statement about what went wrong.
I hope you'll update this to meet what Mozilla requires for incident reports?
List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.
Although the certificates have not been issued in accordance with Mozilla Policy, we are not planning to revoke these certificates.
Could you explain how this complies with Mozilla Policy 6.1? Or was this an area that Entrust Datacard was also not familiar with the changes to in the past 3 years?
ECDSA P-384 with SHA-256 provides 128-bit security strength, which is the same security level as P-256 with SHA-256, which is allowed by the Mozilla Root Store Policy v2.7. However, some Subscribers may have thought that they were receiving 192-bit security strength since the key is P-384. As such, we will advise Subscribers of the issue and will offer certificate re-issue at no cost.
This doesn't seem to meet the level of https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation
Overall, this report, while useful to identifying and disclosure of a failure by Entrust Datacard to follow the same requirements that all CAs are expected to follow, doesn't really help build confidence that the underlying root cause has been addressed, that there's sufficient detail for the community to be assured it's been fixed and for other CAs to learn from it, or to follow the same requirements that all CAs are expected to when an incident happens.
I'm hoping this was just an oversight in a rush to disclose before a CA/Browser Forum call, and that the next reply to this post will be a more suitable report that meets the expectations.
Entrust’s response is deeply concerning on its own. I’ll split this up to a few pieces:
First, the significant lack of detail:
We discussed that we are using both pre-issuance linting and post-issuance linting using zlint. The zlint software used did not detect the error. We do occasionally use the online implementation used with crt.sh, which detected the problem on 17 June 2020. We did review for other bugs with the similar issue and found this one, https://bugzilla.mozilla.org/show_bug.cgi?id=1527423.
So, once again Entrust does not take the step to investigate why their zlint is behaving differently from the crt.sh zlint. This is the second time this has happened, in pretty quick succession.
Also, Ryan was asking are you reviewing these incidents and MDSP on an ongoing basis. Not “Have you gone and searched for incidents similar to yours?” Which is how Entrust responded.
Jumping to the future, we also have more proof that Entrust isn’t really following Bugzilla. When asked for triage logs for various bugs, they can’t provide them: https://bugzilla.mozilla.org/show_bug.cgi?id=1879602#c19
Getting into why & how the mistakes were made:
The certificate profile was changed to support SA-384 in April 2016, so about 10 months before the Mozilla requirement came into place. Unfortunately, the change was not implemented on either CA and the reason has not been determined. We plan to update our process to ensure that the approved certificate profiles are implemented and tested.
Okay, then why did Entrust not make that clear in their incident response? Why do people keep needing to fish information out of Entrust? It is the CA’s job to provide detailed and useful incident response.
Beyond that, it’s extremely concerning that Entrust did not immediately know why a certain change was, or was not, applied to their CA software. This is the same software that has keys to the entire web.
And then we get to the revocation question:
Agree, however we felt that the certificates as issued would protect the Subscribers and the Relying Parties through their validity period. We also reviewed bug https://bugzilla.mozilla.org/show_bug.cgi?id=1527423 and saw that revocation was not discussed or performed for this incident. We were hoping to provide our Subscribers with the same consistency.
This makes no sense. Your obligation to revoke is not determined based on how some other CA behaves.
This does highlight a point I’ve been trying to make though. Root programs are inviting a moral hazard by not taking action against Entrust’s continuous disregard for the BRs, the EVGs, and the requirements of various root programs.
Ryan Sleevi responds to Entrust: (Emphasis mine)
…
We did review for other bugs with the similar issue and found this one, https://bugzilla.mozilla.org/show_bug.cgi?id=1527423.
So in your extensive review, and your ongoing following of activity of mozilla.dev.security.policy, Entrust was unaware of and/or did not perform any examination for the following:
2017-01-24 - Discussion started by Gerv Markham leading to the policy
2019-02-09 - Corey Bonnell raising the issue
2019-03-08 - SSL.com reporting an incident
2019-04-03 - Discussion started by Wayne Thayer
I'm encouraged you were able to locate the DigiCert issue, but it appears no careful analysis of this issue was performed, such as the validity periods of the certificates at the time the incident was reported.
The certificate profile was changed to support SA-384 in April 2016, so about 10 months before the Mozilla requirement came into place. Unfortunately, the change was not implemented on either CA and the reason has not been determined. We plan to update our process to ensure that the approved certificate profiles are implemented and tested.
When can we expect an update on the reason determined? I think it's reasonable to be quite concerned when a CA doesn't implement a change in policy, doesn't follow discussions about violations of that policy, doesn't know why they didn't follow those discussions or makes those changes, and doesn't plan to do anything about the certificates that violated the policy. This gives a very clear impression of a CA that simply doesn't care about adhering to policy, and it's unfortunate that this reply doesn't raise to the level.
If this seems like a harsh or emotional reply, it should be realized that the CA's incident report and handling is a key determination of trust. This is the CA's opportunity to demonstrate, beyond reproach, that they are capable of being trusted, that any failures were exceptional, and have been well researched into what went wrong and what's being done to improve. The subjective evaluation of these incident reports is to avoid the alternative of using an objective process that immediately distrusts CAs, which is far from ideal. So my hope is that, using the resources previously provided about both expectations and positive examples, Entrust will step up here and really look to distinguish itself with a quality incident report, treating any failing of policy as seriously as possible.
…
Agree, however we felt that the certificates as issued would protect the Subscribers and the Relying Parties through their validity period. We also reviewed bug https://bugzilla.mozilla.org/show_bug.cgi?id=1527423 and saw that revocation was not discussed or performed for this incident. We were hoping to provide our Subscribers with the same consistency.
I'm deferring to Ben, as I think Entrust is being grossly negligent here, that the material facts are demonstrably different, and the result is one that inspires little faith in whether or not Entrust is capable of viewing policy appropriately. Least of all because the previous efforts to highlight what is expected of Entrust here is willingly and intentionally being ignored.
I don’t think I need to add more here. Ryan Sleevi says exactly what is on my mind reading this.
Ryan then goes on to explain what a proper timeline could’ve looked like:
Just to make sure to add color about what a detailed timeline would have also included:
2016-11-07: Gerv opens policy issue #5 to introduce this requirement
2017-04: Mozilla sends a communication reminding CAs to carefully review the Policy 2.4 changes, and Entrust "Check here to confirm that Mozilla's CA Certificate and CCADB policies have been reviewed and any necessary changes to your CA's policies or practices will be made by June 1, 2017."
2020-01: Mozilla sends a communication reminding CAs to carefully review the policy differences and discussions, which Entrust declares "We have read, understand, and intend to fully comply with version 2.7 of Mozilla’s Root Store Policy"
2020-05-14: Zakir Durumeric announces a new version of ZLint and where to subscribe to announcements
2020-05-22: A posting of the new version is announced on the list linked by Zakir, including a list of the new lints
I simply find it unfathomable that a response to this incident would be "it was not observed that these CAs were not configured correctly", especially after explicit attempts were made to highlight and emphasize this. It suggests that, despite warranting to the community and Mozilla that Entrust will comply, the statement is merely one of "good intentions" rather than an actual process or procedure to ensure compliance. This might have been acceptable in 2015, but it's unconscionable in 2020 to think that sort of response is appropriate.
Entrust also reviews the Mozilla Policy upon each update and in this case, the certificate profile met the requirements
This is also difficult to reconcile, given the language of 2.4.1, the incident discussion, the subsequent 2.7, and the fact that this was still missed. I cannot see how this statement is remotely true, and that's why it's so deeply troubling, because it's difficult to distinguish whether this is deception, ignorance, or apathy. Ignorance seems difficult to square away, given the statements on m.d.s.p and efforts in policy 2.7 here explicitly to make ignorance an unacceptable answer here, but the alternatives are even more troubling.
Entrust has claimed they monitor MDSP, Bugzilla, and requirements diligently. But whenever it comes to prove that, they fail in doing so.
This bug goes on with a few back-and-forths. I’ve highlighted some interesting points in these discussions:
Entrust promises to review 6 months of previously issued certificates when zlint updates.
Entrust promised that Policy member(s) will be subscribed to notifications on Bugzilla and MDSP.
SIRQ: -1
Entrust: Late Revocation due to SHA-256 hash algorithm
2020-07-08
A couple of weeks after the initial incident, Entrust files their revocation delay incident.
The main points of the incident response are:
Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
Entrust originally took the position that there was no immediate security issue, nor a security issue within the remaining validity period of the certificates. After filing the Incident Report and reviewing with Mozilla, it was determined that the certificates should be revoked. Since revocation is taking place after the 5 day period, this Incident Report has been generated.
There were 606 certificates associated with 142 global customers. Entrust primarily issues certificates to enterprise customers which includes banks, governments and other large financial and commercial customers. It was considered that immediately revoking all certificates would negatively impact the Subscribers and their Relying Parties. As such we are working through a process to provide notice and confirmation. This process causes a delay to revocation, but also provides a better experience the users of the SSL ecosystem, by not providing errors when there is no urgent security issue. Entrust understands that we are responsible for consequences of late certificate revocation.
List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.
Notification provided to all customers.
Reissue and revocation started shortly after notification.
Follow up with all non-responsive customers to confirm revocation and provide time to reissue certificates.
Will follow up on completion timeline.Status: To date 376 certificates unexpired certificates are not revoked.
Once again, Entrust using the “not a security issue” line again. And the action items having no dates and being unrelated to preventing another “Failure to Revoke” incident. At this point I’ll be surprised if Entrust actually did a revocation without throwing a fuss about it.
Ryan Sleevi asks about this, and Entrust responds:
It is our position that revoking the 605 affected certificates within the prescribed deadline would provide significant harm to the Subscriber's website and Relying Party use. It was our decision that the harm caused revoking in accordance with BR 4.9.1 outweighed the risks passed on to the Subscribers and Relying Parties. For this incident Entrust takes responsibility for this decision.
For previous issues, Entrust has been transparent when we have found incidents and have worked hard to revoke certificates in the required timeline. When we have missed the timeline, we have implemented practices to try to prevent similar issues in the future. If there are future incidents (which we are trying hard to prevent), we still plan to revoke with the timeline provided in the BRs. However, we do believe that there are some incidents where quick revocation will not help. Per Mozilla’s statement above, we understand that Mozilla also understands this position.
I’ve come across this behavior from Entrust recently too - and I called them out on it. Their goals seem to be preventing incidents, not preventing failure to revoke.
Interesting enough, in this incident Entrust makes the following promises:
We do know that we made an incorrect initial decision, where we planned to NOT revoke. This made our response and action plan late. In the future our plan will be:
Publish an Incident Report within 1 business day of detection of the incident
Publish a late revocation Incident Report within the required 24 hours or 5 days requirement, as applicable
Advise Subscribers to revoke within 24 hours or 5 days as applicable or provide an explanation why they cannot revoke
Update the late revocation Incident Report with the Subscriber status and the timeline for closure
Ensure that the Incident(s) are listed in the annual audit report
We know that this is just completely not true. Why should we continue to trust the rest of what Entrust is saying?
SIRQ: -1
This marks the end of part 2 of this wild ride. To summarize:
Entrust has decided to allow misissuance after they found out about it in two different incidents:
Entrust: Printable String Constraint Failure
Entrust: SHA-256 hash algorithm used with ECC P-384 key
Entrust keeps using the “No security impact” line over, and over again. With no data backing it up.
Entrust keeps arguing about the requirements of the BRs.
Out of these 7 incidents, Entrust discovered the issue on their own in only three of them. In three of the incidents, Entrust discovered the problem through external reporting. And finally, one of the incidents was discovered through WebTrust Audits.
Out of these 7 incidents, Entrust argued about the requirements in some capacity in 2 of them.
Acknowledgements:
David Gonzalez Garcia for helping me figure out the Censys query for finding misissued certificates.
Boet de Willigen for reviewing an early draft of this post.