| ▲ | sippingabonedry 5 hours ago |
| Here's a question for Mozilla et. al.: It's cute you have a magic DIY CRL. You accepted these assholes into your root program. They lost the KEYS. What is the screening process for CA's that can't be bothered to use a HSM? Even Honest Achmed wasn't this careless. |
|
| ▲ | john_strinlai 4 hours ago | parent | next [-] |
| >What is the screening process for CA's it's done in the open, and you're even allowed to voice your cute opinion during the multi-week public commentary periods. here is an overview https://wiki.mozilla.org/CA/Root_Inclusion_Overview |
|
| ▲ | eqvinox 4 hours ago | parent | prev | next [-] |
| They didn't lose the keys, a sub-CA did. Which is to say, sub-CAs in itself are a giant loophole that needs plugging. Especially since AFAIK nobody is bothering with name constraints (RFC5280 section 4.2.1.10). |
| |
| ▲ | agwa 3 hours ago | parent | next [-] | | eMudhra is also a root CA operator. One root CA operator cross-signing another root CA operator is a good thing actually, and it's what allowed Let's Encrypt to work before their root certificate was widely trusted. Issuing sub CAs to non-root operators has historically been a big loophole though it's not as bad these days since multiple root programs now require approval before CAs can do it. | | |
| ▲ | sippingabonedry 3 hours ago | parent [-] | | Didn't Let's Encrypt have to jump through all sorts of hoops to prove they were competent and trustworthy before that happened? Now it's coming out these guys used "4" as a private key. That's a crazy amount of incompetence and malfeasance. Did they vibe-code a CA? HOW DOES THIS HAPPEN? I am dumbfounded. You couldn't even do this if you installed Microsoft Small Business Server 2008 today, unpatched, with the CA on default settings. | | |
| ▲ | agwa 3 hours ago | parent [-] | | eMudhra had to jump through even more hoops. Obviously the system failed here, but it's a failure of a root certificate operator, not a sub-CA operator as claimed by eqvinox. |
|
| |
| ▲ | woodruffw 4 hours ago | parent | prev | next [-] | | The reason nobody bothers with NCs is because they don't work very well in practice. They also have their own baroque matching rules that are not intuitive if you're from the land of UNIX globs. (In fairness this is a self-fulfilling prophecy: a lot of validators handle NCs poorly or not at all, so there's no impetus to rely on them. But that's not something we can really save in the Web PKI's current state.) | | |
| ▲ | eqvinox 4 hours ago | parent [-] | | > But that's not something we can really save in the Web PKI's current state. I agree with your assessment but it's not an excuse to give up without trying. I hope this is just because I'm not looking in the right places, but I don't see people trying. What really makes me salty is that there was enough energy to mess with the rules around EKU, the primary effect of which is that non-browser software is now starting to just ignore the EKU bits. Even if it would've amounted to nothing, I'd really rather that effort had gone into NCs. | | |
| ▲ | woodruffw 3 hours ago | parent [-] | | I think a lot of people have tried! The reason EKUs stuck where NCs haven’t is because EKU rules are simple (in relative terms) and OpenSSL didn’t make as much of a mess out of them. | | |
| ▲ | eqvinox 3 hours ago | parent [-] | | I can't help but read your post as "OpenSSL didn't make a mess of EKUs so the CA/B had to fill that role instead" :/ (I really am salty about the EKUs. In a few years the EKU field will just be useless, due to operational annoyance driving devs to ignore it. Except in browsers of course.) |
|
|
| |
| ▲ | sippingabonedry 4 hours ago | parent | prev [-] | | The situation is even worse than I thought. They hold intermediate certificates issued by TWO different root CAs, neither of which they operate. So two separate entities didn't bother to read their certificate policy or inspect their operations. Have we not learned anything from past mistakes? Roots should be responsible for all their sub-CAs, full stop. If they don't trust them enough to accept that responsibility, then the system is broken. | | |
| ▲ | mook an hour ago | parent [-] | | If you mean Comodo and Setigo, they're the same company, pre- and post-rename. Let's just say they've had issues with signing sub-CAs before where those sub-CAs went on to misuse them before… looks like it was around 2011? |
|
|
|
| ▲ | bombcar 5 hours ago | parent | prev [-] |
| IIRC up until very recently the screening process was "they report that they're good boys." |
| |
| ▲ | jcranmer 4 hours ago | parent [-] | | The screening process has been more involved in that since around the late 2000's. I wouldn't call 20 years "very recently," especially in the context of the history of the web. |
|