Correct, the violations are minor and should be trivial to deal with.
The problem in this case is that Entrust displayed a complete disinterest into actually solving the underlying issues. Doing an oopsie is one thing. Doing an oopsie, lying about it, refusing to take precautions, and failing to take measures to prevent a repeat despite promising to do so? Completely different story.
If they can't be trusted to respond properly to minor administrative issues, why should they be trusted to respond adequately during a real security incident?
Indeed one of the things that got raised is that they do not appear to have adequate resources to conduct a mass revocation if signing key material were lost, because they rely on slow manual processes. If they are too constrained to do even minor things, then they REALLY cannot respond to emergencies.
Since contents of certificates contents sadly often diff there was a ballot to streamline the contents to lessen the burden on implementations to interpret the differences.
Entrust missed/ignored the updates to how certificates were supposed to be formed and when caught declined to revoke the incorrectly issued ones (because it's probably a more or less manual process for many admins working in a pre-Let's Encrypt style of fashion) and they didn't want to inconvenience their customers and assumed that they themselves were the important party in the equation (CA's was that historically compared to site-admins).
The certificate industry has always been quite ad-hoc with CA's being entitled middlemen, we have Let's Encrypt and almost ubiquitous encryption now because browser makers and other internet actors saw security as more important than protecting the CA's business and now that LE is established Google,etc aren't the slightest interested in pampering CAs if they aren't interested in cleaning up the system.
They are very minor, but because the consequences of an mis-issued certificate can be so high, there’s an explicit policy that misissued certificates must be revoked and reissued promptly. The distrust was due to them refusing to comply with the policy and outright stating that they did not intend to comply in future incidents either.
There are some issues that are bad, but most of these issues with the _certificates_ are minor.
The problem is that to be a CA in the root stores you agree to (and entrust voted in support of) a pile of rules, and entrust demonstrated a complete disinterest in complying with those rules.
The reason for removing trust is not the severity of the original errors, it's the the severity of errors in the response.
1. The BRs requires revocation of invalid certificates with 5 days unless there is an exceptional reason not to. Entrust did not.
2. In the event a CA discovers that they are mis-issuing certificates they are required to stop issuing until they have resolved the error. In this case not only did entrust not do this, but they explicitly stated - after the issues were raised, and they were already told they were failing to revoke certs in the required time frame - that they were intentionally continuing to mis-issue
3. They repeatedly made errors in the past, promised to correct them, and then kept making the same errors
4. They made claims they were trying to get customers to prepare for revocation in the require 5 day window, but then it turned out they were telling customers that they had 30+ days (which was only discovered when one of the relevant customers forwarded info to someone else)
5. When a CA discovers miss issuance they are required to file an incident report, and provide detailed information about how it occurred, why it was not caught, what remediating steps are being taken, and what mechanisms are being introduced to ensure a similar failure cannot occur in future. None of Entrust's responses came close to this, until the chrome root store rep came in to say "this is unacceptable", and even then their "improved" reports were incomplete and lacked sufficient detail.
6. Once they were finally doing the basic steps they were meant to have done the moment they learned of the miss-issuance they repeatedly failed to produce an accurate set of the impacted certificates (as in the provided a list and people outside of Entrust were able to immediately turn around and say "but these certs are also broken, why aren't you listing those details")
A LOT of minor fuck ups which demonstrates Entrust is (likely) not malicious, they just stupid and don't care how to do things correctly.
How long until they fuck up something serious?
This reminds me about discussion about Russian Goverment's NUC Root CA (not trusted by default in Chrome/Firefox, Trusted by Yandex Browser only with some additional verifications to prevent abuse by goverment). Discussion was not about why this cert was necessary in first place, it was about it's creation violating Russian laws and procedures AND violate a lot of technical rules.
A lot of people just said - this cert is necessary and it's clear who made it so why we should look to "minor details"?
(Links - in Russian https://habr.com/ru/articles/666520/ / https://habr.com/ru/articles/708970/ )
Comments
Can someone ELI5 what the violations linked in the first line are? They seem pretty minor to me but I don't understand certs
Correct, the violations are minor and should be trivial to deal with.
The problem in this case is that Entrust displayed a complete disinterest into actually solving the underlying issues. Doing an oopsie is one thing. Doing an oopsie, lying about it, refusing to take precautions, and failing to take measures to prevent a repeat despite promising to do so? Completely different story.
If they can't be trusted to respond properly to minor administrative issues, why should they be trusted to respond adequately during a real security incident?
Indeed one of the things that got raised is that they do not appear to have adequate resources to conduct a mass revocation if signing key material were lost, because they rely on slow manual processes. If they are too constrained to do even minor things, then they REALLY cannot respond to emergencies.
Since contents of certificates contents sadly often diff there was a ballot to streamline the contents to lessen the burden on implementations to interpret the differences.
Entrust missed/ignored the updates to how certificates were supposed to be formed and when caught declined to revoke the incorrectly issued ones (because it's probably a more or less manual process for many admins working in a pre-Let's Encrypt style of fashion) and they didn't want to inconvenience their customers and assumed that they themselves were the important party in the equation (CA's was that historically compared to site-admins).
The certificate industry has always been quite ad-hoc with CA's being entitled middlemen, we have Let's Encrypt and almost ubiquitous encryption now because browser makers and other internet actors saw security as more important than protecting the CA's business and now that LE is established Google,etc aren't the slightest interested in pampering CAs if they aren't interested in cleaning up the system.
They are very minor, but because the consequences of an mis-issued certificate can be so high, there’s an explicit policy that misissued certificates must be revoked and reissued promptly. The distrust was due to them refusing to comply with the policy and outright stating that they did not intend to comply in future incidents either.
There are some issues that are bad, but most of these issues with the _certificates_ are minor.
The problem is that to be a CA in the root stores you agree to (and entrust voted in support of) a pile of rules, and entrust demonstrated a complete disinterest in complying with those rules.
The reason for removing trust is not the severity of the original errors, it's the the severity of errors in the response.
1. The BRs requires revocation of invalid certificates with 5 days unless there is an exceptional reason not to. Entrust did not.
2. In the event a CA discovers that they are mis-issuing certificates they are required to stop issuing until they have resolved the error. In this case not only did entrust not do this, but they explicitly stated - after the issues were raised, and they were already told they were failing to revoke certs in the required time frame - that they were intentionally continuing to mis-issue
3. They repeatedly made errors in the past, promised to correct them, and then kept making the same errors
4. They made claims they were trying to get customers to prepare for revocation in the require 5 day window, but then it turned out they were telling customers that they had 30+ days (which was only discovered when one of the relevant customers forwarded info to someone else)
5. When a CA discovers miss issuance they are required to file an incident report, and provide detailed information about how it occurred, why it was not caught, what remediating steps are being taken, and what mechanisms are being introduced to ensure a similar failure cannot occur in future. None of Entrust's responses came close to this, until the chrome root store rep came in to say "this is unacceptable", and even then their "improved" reports were incomplete and lacked sufficient detail.
6. Once they were finally doing the basic steps they were meant to have done the moment they learned of the miss-issuance they repeatedly failed to produce an accurate set of the impacted certificates (as in the provided a list and people outside of Entrust were able to immediately turn around and say "but these certs are also broken, why aren't you listing those details")
and so on and so forth.
Google's post to CCADB provides more details than the blog post: https://groups.google.com/a/ccadb.org/g/public/c/29CRLOPM6OM...
A LOT of minor fuck ups which demonstrates Entrust is (likely) not malicious, they just stupid and don't care how to do things correctly. How long until they fuck up something serious?
This reminds me about discussion about Russian Goverment's NUC Root CA (not trusted by default in Chrome/Firefox, Trusted by Yandex Browser only with some additional verifications to prevent abuse by goverment). Discussion was not about why this cert was necessary in first place, it was about it's creation violating Russian laws and procedures AND violate a lot of technical rules. A lot of people just said - this cert is necessary and it's clear who made it so why we should look to "minor details"? (Links - in Russian https://habr.com/ru/articles/666520/ / https://habr.com/ru/articles/708970/ )