4 ms·

I 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 ha

I 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 ago
There was something wrong. They hadn't been issued in accordance with the baseline requirements.
hmmm-i-wonder 2y ago
The 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 ago
The 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 ago
Revocation 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 ago
No. 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.

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 ago

There was something wrong. They hadn't been issued in accordance with the baseline requirements.

hmmm-i-wonder 2y ago

The 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 ago

The 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 ago

Revocation 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 ago

No. 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.