4 ms·
Reads to me like Digicert is hiding behind the TRO to protect themselves from upset customers over following the procedures they should have followed. I don't t
by jeroenhd 2y ago
Reads to me like Digicert is hiding behind the TRO to protect themselves from upset customers over following the procedures they should have followed. I don't think they want to update their legal work to prevent customers from legal action over revocation, legal action has been working in their favor so far.
For a company whose entire business is verifying company names and handling the CA process, Digicert seems rather unwilling to actually stick to the process. They can't help having a TRO filed against them by customers with incompetent tech such as Alegeus Technologies LLC, but this isn't the first time they've failed to follow the appropriate processes.
Going through the courts to stop negative discourse seems rather crass for a CA. I don't understand why a company that has been subject of suspicion and doubt lime Digicert would do such a thing unless it's a last-ditch effort to get the heat off their backs.
I'm sure their clients love Digicert for not forcing them to replace their certificates at the appropriate times, but they're in for a surprise when this whole thing blows up and they suddenly need to find another cert vendor when Digicert gets delisted.
- michaelt 2y agoI dunno, seems to me in the TRO case there wasn't anything wrong with the certificates that had been issued. There wasn't any suggestion the the certificates had been issued to the wrong party or anything like that. When performing DNS verification there's supposed to be an underscore in a record, which protects sites that let their users control arbitrary subdomains - you know, dyndns and things like that. Digicert mistakenly didn't ask the customer to include an underscore. Could have been a problem, if Alegeus was a dyndns provider - but they aren't. Then Digicert spent a load of the 24 hour disclosure window checking things on their end, then e-mailed the customers after office hours so when they get in the next day they barely had any time to respond. The only "incompetent tech" here is the assholes who decided on the policy that certificates be urgently revoked, as if they'd been issued to the wrong person, when they hadn't been issued to the wrong customer.
- Thorrez 2y ago>Could have been a problem, if Alegeus was a dyndns provider - but they aren't. AFAIUI, Alegeus was just 1 customer of Digicert. But Digicert has tons of customers. Just because there wasn't a problem for Alegeus (due to Alegeus not being a dyndns provider), doesn't mean there weren't problems for other Digicert customers.
- wbl 2y agoThere was something wrong. They hadn't been issued in accordance with the baseline requirements.
- hmmm-i-wonder 2y agoThe middle ground here is DigiCert should have been able and continued with the revocation of all the other certificates not impacted by the TRO within the policies and contractual agreements it has. The policy and its designers aren't incompetent, the intention is to ensure security first when fact-finding can take time to establish a subset of actual abuse. This is common in IT/Security and is clearly communicated in the policy customers agree to as well as something agreed on by all CA's. Security > Uptime is the baseline, and while you may disagree with that and have good arguments for the contrary, the argument is much wider than us and has been extensively hashed out in the working groups and discussions around this and other similar issues and is implemented this way by consensus while weighing valid arguments for different approaches and pros and cons.
- cjbprime 2y agoThe fact that those certificates had been issued without a secure method of verification is the thing that was wrong with those certificates. Dyndns is not the only use case for having someone control a subdomain without having the full trust of the root domain.
- crote 2y agoRevocation rules are intentionally very strict, in order to prevent CAs from weaseling out of them. If you leave open any possibility of a CA delaying or refusing revocation because of some form of "it's an administrative issue, it isn't that serious anyways", every incident will inevitably result in a weeks-long discussion about the real impact of the incident and whether this one is "serious enough" to require immediate action. In the past CAs have been more than happy to lie and downplay incidents, because they know their customers don't like revocations and are going to consider switching to a competitor. Maybe not a big deal in practice for a technicality, but it does mean that CAs can not be trusted to always be truthful - and that in turn extends to serious incidents. This is obviously really bad for the web PKI as a whole, so the rule is that any violation of the rules, no matter how small or nitpicky, must be treated as if it were a serious security incident. Don't agree with the rules or think the rule is interpreted the wrong way? File a report afterwards to review the rules. The entire business of a CA is to be a trusted third party. If you can't be trusted to always follow the rules exactly to the letter, you shouldn't be a CA. Behaving predictably is more important than being right about some technical minutiae regarding the security impact of some incident.
- 12_throw_away 2y agoNo. Our cert infrastructure needs to meet the highest standards possible, this is not an area where "welp, no harm done, don't worry about it" is acceptable.
- hmmm-i-wonder 2y agoThis seems like a misunderstanding of the TRO. Alegeus, a client of DigiCert, filed a court motion to stop DigiCert from revoking their certificate. The courts granted the temporary restraining order. There is no "update their legal work to prevent customers from legal action" that can avoid a temporary restraining order that is ordered by the courts to provide time to establish facts. Its simply how the legal process works. "they can't help but" seems unfair as the issue was the client Alegeus was unable to replace their certificates in the revocation timeline. Further "Going through the courts", they didn't go to the courts a client of theirs did. Digicert is absolutely not blameless. Outside of the TRO, they have failed to meet revocation windows before and yes, are likely using the TRO in this instance as a shield for that. However the TRO itself is a concerning development that all CA's need to consider depending on their legal jurisdiction, as it could put companies in a bind of being legally ordered to not to complete something they are contractually and legally required to do within the required timeline and interrupt standard security practices in cases like this.
- lokar 2y agoWould a judge not consider potential harm to each party if the TRO is granted or not? If the CA could credibly point out they would face severe consequences for failure to revoke, could that have an impact on?
- bluGill 2y agoThey should - but only if a good lawyer points that out to the courts. Remember the courts are not experts in the technical details in question (and should not be - there are far more details that could come before the court than any human has time to learn), the job of lawyers is to quickly give them enough education to figure it out. In "Common law" when something goes before a court in slightly different situations the second court will look at what the last one decided to see if it makes sense and if they agree. Then the third time looks at both the previous. After many many cases courts will have seen all the arguments and made decisions and so there is no need to educate the court anymore, they will just look at what was done before and decide the same thing. Not all courts follow the "common law" above though, and I'm not clear how the other systems are different. (I've only lived in common law areas)