23 ms·
Mozilla, Microsoft yank TrustCor's root certificate authority
- bombolo 4y agoI like how periodically we briefly get reminded that PGP's web of trust really is the superior system but we forget about it in a few minutes and move on.
- tgsovlerkhgsel 4y agoIt really isn't, though. It's great in theory but breaks down in practice because the average user has neither the patience nor knowledge to manually deal with that stuff, nor should we expect them to.
- mastax 4y agoInstead we give the keys to the kingdom to everyone who shows up with a letter of recommendation.
- moring 4y agoIt isn't superior because it isn't easy to use. It's only superior on the "secure" side. It would be nice if that concept was re-implemented in an actually superior product, starting with "will the average user be able to use it in their daily communication?"
- brnt 4y agoPGP's ceremony is no solution for anything. A Signal-like experience (TOFU, key verification if you wish, alerts when keys change) would be superior, if people were trained more (and recall how hard is was to tell people to look for the green padlock). Autocrypt is an attempt (with little uptake). Certificates not only about encryption, but also about authority: am I really connected to my bank? PGP only solves that if I already have verified keys, which is the hardest part left unsolved. Unfortunately, proprietary two factor apps seems to be the way this is increasingly solved. Even further removed from a superior system (but, apparently, practical).
- XorNot 4y agoMost of the whole PGP system is inadequate for real use, but it points towards a model and interface which is: most people for most encryption simply want to know the answer to "is this my bank as my government/insurance company etc. believes it is?" and that sort of key would essentially be distributed by consensus. But the standard we've got is, once you're "in" to the CA root store, technically you can issue certificates for anything in any context, and the way we interact with them is to simply trust them uniformly. What we need is a system which let's us easily contextualize the actual trust problem we're solving with a connection: i.e. "I'm contacting a bank in <country>, so I want to know that the government of that country thinks its a bank, (maybe through the reserve bank of that country which expresses trust as to that identity". Chains of trust which make sense for the relationship. As it is, if I visit say - pm.gov.au and check the certificate I get that it was issued by GlobalSign. Who are they? Well, they're in the Root CA store which is why they're involved because that was the only requirement. But what I want to actually know is "Am I talking to the Australian government and at what level?"
- mschuster91 4y agoThe problem isn't made easier by there being two completely distinct questions to be answered: - connection security: are the crypto credentials being used for signing e-mails or encrypting web traffic belonging to the entity in question? This should have been solved by putting the fingerprints into DNS so that clients can validate it on their own instead of having to trust a CA. DNSSEC and certificate pinning would have been the answer, but both are incredibly complex to set up and littered with failure scenarios that may be very difficult to recover from, but in the end it got "solved" by LetsEncrypt/ACME where the CA acts as a proxy. For e-mail, it got solved better by DKIM, but that's only applicable to the scenario "an email server wishes to check if an email it received from example.com actually originates from example.com", but not for "an email client wishes to send an encrypted email to foo@example.com and needs the public key for this mailbox". - connection authenticity: is the server a client is talking to (e.g. bank.com) actually belonging to the legal entity the user expects it to be? That one is what CAs were originally designed to verify and where a much larger amount of trust is placed on the CAs doing their job correctly. One idea to do that was SSL EV certificates, but for whatever reason these fell out of favor - and right now, there is no replacement at all for this use case. Additionally, the situation is made even more complex by legal or compliance requirements, e.g. banks who have to record virtually everything their employees do. For that, they have to break HTTPS by providing their own root certificate.
- CJefferson 4y agoHow is it more secure? With certificate transparency, there has been almost no invalid certificates found, and anyone who produces one is immediately struck off. I can't really imagine how web of trust would let me (for example) securely connect to hellbunny.com, a website I have no direct connection to,.and isn't that famous.
- bombolo 4y agoWhy are root CA authorities holding on to private keys and sending them around? https://www.techtarget.com/searchsecurity/news/252436120/23000-Symantec-certificates-revoked-following-leak-of-private-keys https://www.techtarget.com/searchsecurity/news/252436120/230... The "trusted" party sometimes fails spectacularly it seems. > hellbunny.com, a website I have no direct connection to,.and isn't that famous. And what do you know about that certificate? That some root CA signed it. Do they follow a proper process? I don't care about random websites. For those letsencrypt is fine. But for banking or paying taxes I want some more checks done. And they aren't provided.
- tialaramex 4y ago> Why are root CA authorities holding on to private keys and sending them around? They aren't. In the story you link Trustico are a reseller. Once Trustico revealed that they had these keys which they shouldn't have, all the certificates were invalidated because they're worthless, the issuing CA - DigiCert - did exactly what we want them to do. If the corner store near me sells cans of Coke which they have poisoned, that's not a problem with Coca-Cola, it's problem with that local store. The local cops should get involved, and yes as happened here, the company whose product reputation they harmed should be angry about that and cut ties to them, no more Coke branded fridge if the store owners somehow stay in business (and indeed in my hypothetical if they avoid jail).
- tialaramex 4y ago> And what do you know about that certificate? That some root CA signed it. Do they follow a proper process? The purpose of m.d.s.policy, the discussion group where the decision to distrust Trustcor was made, is to oversee these root CAs. As part of that, we require them to use at least one of the Ten Blessed Methods (there aren't actually currently ten of them) to decide whether a subscriber is entitled to certificates for particular DNS names. You can read in the CAB BRs https://cabforum.org/baseline-requirements-documents/ https://cabforum.org/baseline-requirements-documents/ what the currently allowed Blessed Methods are in section 3.2.2.4 Validation of Domain Authorization or Control -- each method is numbered e.g. 3.2.2.4.19 is the most often used Let's Encrypt (ACME standard) web site authentication. You can also read in the CA's own documentation how they claim to implement one or more of the Blessed Methods, for example Let's Encrypt offer 3.2.2.4.19 and explain that, but they don't offer say 3.2.2.14 which is sending out emails with a magic random number in them to a domain contact's email address.
- otikik 4y agoNot really superior if no one uses because they can't figure it out.
- bombolo 4y agoWell the current system we basically sign everything as long as the domain on the certificate matches what's registered on the DNS. If the certificate says "Company AB", nobody checks if that's true.
- tialaramex 4y agoIf the certificate says "Company AB" the CA is required to check that's true, there's a set procedure to do so. If you ask Let's Encrypt for a certificate saying "Company AB" they won't give it to you, because they don't follow such procedures and so they know they can't issue such certificates. But, this is not very useful because: * Consumers generally have no idea who "Company AB" are. You wanted funny-cat-gifs.example not "VXK Enterprise LLC of New Jersey" who might happen to run funny-cat-gifs.example. Lots of famous brands are actually offered by companies with unrelated names, so then you're asking the CA to vouch for the brand name, which is an extra layer of indirection... * Jurisdiction is a thing. Maybe I trust Greasy Geoff's Cider And Pork, but alas I was thinking of the Kansas Greasy Geoff's, not the one from Missouri. * Machines can't do anything with this so it's only useful in the rare case a human spent time thinking about it, whereas the DNS name check is something the machine cares about for every single HTTP transaction, of which often several per second happen.
- upofadown 4y agoThe OpenPGP standard trust stuff is certainly represents a more flexible system (wildcards match on a regular expression) and at this point is a simpler and more straightforward system. It ultimately solves more or less the same problem. TLS links a key fingerprint (ultimately the identity in any cryptographic trust system) to a host name. PGP links the key fingerprint to a name and email address (although the standard does not prevent you from linking, say, your phone number as well). So in either case we link the fingerprint to a more convenient alphanumeric string. That's it, that's all we are doing here. The whole trick is in what you think that alphanumeric string represents. I sometimes fantasize about a world where the head office of a bank has a giant QR code literally chiselled into the stone of the building representing the key fingerprint of their root identity. That way anyone that walks by can verify all the bank's identities down to the individual employee simply by snapping a pic with their phone. Part of the responsibility of someone working there would be to check the QR code every morning to ensure that no one had come in the night with a jack hammer and concrete...
- dang 4y agoRelated: Concerns about Trustcor - https://news.ycombinator.com/item?id=33541718 https://news.ycombinator.com/item?id=33541718 - Nov 2022 (36 comments) Mysterious company with government ties plays key internet role - https://news.ycombinator.com/item?id=33532288 https://news.ycombinator.com/item?id=33532288 - Nov 2022 (3 comments) Mysterious company with government ties plays key internet role - https://news.ycombinator.com/item?id=33519020 https://news.ycombinator.com/item?id=33519020 - Nov 2022 (2 comments)
- sieabahlpark 4y ago
- olliej 4y agoMeanwhile the EU is considering legislation that would require all browsers to recognize and accept any company that pays a fee, irrespective of how clearly untrustworthy that company is. So in the future it could be illegal in the EU for a browser to drop a CA, even when they’re caught doing objectively fraudulent acts. All because a bunch of MEPs are presumably being paid off by CAs who want to get legislatively mandated rent payments
- dane-pgp 4y ago> irrespective of how clearly untrustworthy that company is. Isn't that a bit of an exaggeration? Surely what the EU is proposing is that browsers have to accept just those companies which pay the necessary fee and which some EU body declares to be trustworthy. You're right, though, that this still adds to the attack surface, because now you have to trust not just your browser vendor, and all the CAs that they trust, but also this EU body and all the CAs that they trust. (For those who haven't been following, here's what the EFF has to say about it: https://www.eff.org/fa/deeplinks/2021/12/eus-digital-identity-framework-endangers-browser-security https://www.eff.org/fa/deeplinks/2021/12/eus-digital-identit... )
- tinus_hn 4y agoWhat’s to prevent the EU from declaring itself trustworthy?
- hulitu 4y ago> Mozilla, Microsoft yank TrustCor's root certificate authority One of many. Trusted root is ... funny.
- stevewatson301 4y agohttps://archive.ph/6KH1W https://archive.ph/6KH1W
- codedokode 4y agoDon't you think that it would be better if certificate authorities were limited to certain TLDs? For example, a company from country A limited to A's national TLD? This way even if they are ordered to produce a fake certificate, they can only decrypt traffic for country A's sites. Also browsers should display a warning when a certificate issuer for a website changes.
- XorNot 4y agoWhat I don't get is how this wasn't thought up to be put into the SSL/TLS standard when it was built. How did we wind up with infinitely powered root certification authorities?
- dikei 4y agoThe current PKI is geared toward ease-of-use and adoption. It can also be turned completely around: only trust a single root certificate. This design is often used in client authentication: each client need to get its certificate signed by the one single CA that's trusted by the server.
- XorNot 4y agoRight but implementation wise we've never implemented as a default anything else. Domain suffix pinning is available as an extension, but that's all it is - very few TLS stacks support it and that's unlikely to ever change.
- moring 4y agoIs this actually part of the standard? AFAIK TLS allows/demands to authenticate one or both sides via certificates, and defines a mechanism to delegate trust via certificate chains. It does not, AFAIK, define how trust is established, and my guess is that the standard authors realized that this is an infinitely complex topic that should not be intermixed with the technical and cryptographic side of the problem. It just turns out that delegating trust to root CAs, CAs, and browser/OS vendors (the latter via built-in certificate lists) makes it easy for the end user.
- tptacek 4y agoYou will live your whole life and never see a funnier CA response on m.d.s.p. that TrustCor's response to Mozilla, Apple, and Google cornering them on the shady stuff they seemed to have been up to. The TrustCor representative is clearly staring death directly in the face and doesn't realize it, instead trying to brazen their way through it. https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/WJXUELicBQAJ https://groups.google.com/a/mozilla.org/g/dev-security-polic...?
- hn_go_brrrrr 4y agoShe casually drops half way through that's she's actually the largest shareholder. Talk about an own goal.
- ethbr0 4y agoWhy would that matter?
- duped 4y agoThey're arguing about ownership and corporate officers.
- ethbr0 4y agoYes, but the fact that she's the largest shareholders seems immaterial to identifying the corporate officers. And as for ownership, wouldn't knowing the person you're talking to is the largest shareholder enhance their credibility to negotiate and discuss issues with you?
- hn_go_brrrrr 4y agoIt might, if said largest shareholder weren't obfuscating the issues as much as possible.
- zchrykng 4y ago
- charcircuit 4y agoIt seems like everyone was biased against TrustCor because they didn't want their privacy violated. A separate company used an SDK which later was classified as malware and now TrustCor is no longer trusted. That is pretty unfair.
- stefan_ 4y agoSince there was substantial evidence that these were one and the same company. The CA had no substantial public certificate issuing program regardless so kicking it out was an easy decision either way (and begs the question what exactly it is they were doing to justify the multi million dollar operating costs of a root CA).
- charcircuit 4y ago>there was substantial evidence circumstantial evidence, but nothing that was definitive >The CA had no substantial public certificate issuing program So just because they don't have enough customers they should be removed? This just promotes centralization of trust.
- DoctorNick 4y agoIt really doesn’t matter if it was circumstantial or not. When presented with such evidence, the TrustCor rep was extremely evasive. This isn’t a court of law; if a Root CA can’t be up-front about explaining evidence that calls their trust into question, then they cannot be trusted and deserve to have their certificates yanked.
- dcow 4y agoThey were under attack. I actually read the whole thread and they were crystal clear.
- ranguna 4y agoYeah I personally feel for the rep, they were indeed under attack. But there is no going around it, a company that advertised a product as being e2e encrypted when it really was not, having multiple levels of ties with the CA was enough to deem the CA as unfit. I agree with this conclusion because the CA ecosystem is a fragile one if not governed strictly, since the risks are of the highest concern to the general use of the Internet.
- KingOfCoders 4y agoI especially liked the marketing talk "is an incredibly sophisticated and sufficiently complex system with many components." towards techies of Mozilla, Google and Apple.
- lloydatkinson 4y agoIt's the type of response that crypto bros use when their latest pyramid scheme collapses (eg. FTX).
- mnw21cam 4y agoIt's also the exact opposite of what you want in a certificate authority. You want simple, secure, and dependable, not complex, hard to verify, and easy to game.
- CoastalCoder 4y ago> hard to verify, and easy to game. Did you mean to write, "easy to verify, and hard to game."?
- easrng 4y ago> not complex, hard to verify, and easy to game.
- CoastalCoder 4y agoMy mistake, thanks for the correction. I parsed it as "(not complex), (hard to verify), and (easy to game)". I think I would have taken the author's meaning better if they used "or" or "nor" in place of "and".
- deleted 4y ago[deleted]
- pelagicAustral 4y ago
- KingOfCoders 4y agoNuke line of thread "if our concerns have not been resolved by November 22 and further investigation and discussion is still needed, then set “Distrust for TLS After Date” and “Distrust for S/MIME After Date” to November 29, 2022"
- charleyablaze 4y agoFollowed up yesterday with: "Certificate Authorities have highly trusted roles in the internet ecosystem and it is unacceptable for a CA to be closely tied, through ownership and operation, to a company engaged in the distribution of malware. Trustcor’s responses via their Vice President of CA operations further substantiates the factual basis for Mozilla’s concerns. [...] Our assessment is that the concerns about TrustCor have been substantiated and the risks of TrustCor’s continued membership in Mozilla’s Root Program outweighs the benefits to end users. In line with our earlier communication, we intend to take the following actions: 1. Set “Distrust for TLS After Date” and “Distrust for S/MIME After Date” to November 30, 2022, for the 3 TrustCor root certificates (TrustCor RootCert CA-1, TrustCor ECA-1, TrustCor RootCert CA-2) that are currently included in Mozilla’s root store. 2. Remove those root certificates from Mozilla’s root store after the existing end-entity TLS certificates have expired."
- DonHopkins 4y ago>Trustcor’s responses via their Vice President of CA operations further substantiates the factual basis for Mozilla’s concerns. So Mozilla is flatly stating that Rachel's Gish galloping bullshit responses in the discussion were a significant part of the reason they don't trust her. She should have just followed a good lawyer's advice and kept her mouth shut, because she made her own problems much worse with her own words.
- loeg 4y agoNot exactly. On November 22, it was extended: > The discussion thus far is appreciated and has been both informative and constructive. My post on November 8 indicated that if our concerns have not been resolved by today (November 22) and further investigation and discussion is still needed, that we would set the “Distrust for TLS After Date” and “Distrust for S/MIME After Date” to November 29, 2022, for the 3 TrustCor root certificates. However, we’d like to allow more time for any additional dialogue or external developments to transpire prior to sharing our intended course of action. We will continue our assessment and share out necessary next steps on Wednesday, November 30.
- lizardactivist 4y agoStay the heck away from these small-time CAs. In particular if they are based in North America or have any ties to the US Goverment.
- Hackbraten 4y agoAccording to the article, TrustCor doesn’t even own a physical mailbox. I don’t want to imagine how and where they might be keeping their root CA private key material.
- ikiris 4y agoLast I checked, servers don't need a mailbox to operate, even for long periods of time.
- Hackbraten 4y agoThe idea of keeping a CA root certificate on a server sounds pretty reckless. I sincerely hope that no root CA has done that, ever!
- CoastalCoder 4y agoOut of curiosity, where do companies keep really important private keys? A thumbdrive in some safe, and a few printed-out copies of the key just in case the thumbdrive fails?
- Hackbraten 4y agoThese resources explain it quite well, I think: - https://en.wikipedia.org/wiki/Key_ceremony https://en.wikipedia.org/wiki/Key_ceremony - https://cryptography.fandom.com/wiki/Root_Key_Ceremony https://cryptography.fandom.com/wiki/Root_Key_Ceremony You can even watch recordings of selected ceremonies on YouTube. Some of them are several hours long.
- jenny91 4y ago
- dcow 4y agoI’m pretty disappointed by this outcome. I read the entire thread. If you skim the thread and just read the sensational responses then it paints a pretty grim narrative of a CA that cant be transparent. But if you actually read Rachel’s responses she responds to every single accusation several times over. Yeah it’s a word swamp to wade through and the repeated context was annoying, but her company is under attack… what would you do? Would you not try to provide as much rebuttal as possible? It’s pretty… idk… irreverent to take the stance: oh gosh look at this person squirming under pressure to defend themselves why would they do that they must be guilty and malicious. I can smell it! It really feels like a perversely inappropriate forum for discussing a complicated issue like that. Rachel wasn’t trying to deceive so much as she was tying to set guidelines for appropriate review of the material at hand. And then the comment at the end to her when she was simply trying to make sure the transition happens cordially without breaking existing certificates as seems is the intention, “why does Microsoft need to answer to you?”, is just snotty on a whole new level. Honestly it makes me think we need special courts and some sort of process to handle this stuff because people don’t have time to… process. I am probably in the minority here, but I can’t help but feel like Rachel was a victim of a sloppy but effective smear campaign. I suspect the outcome would have been different if this was handled in a court of law.
- stevewatson301 4y agoI'm not seeing where she's provided answers to the questions that really matter. All she's done is to talk in a patronizing manner to the CA members regarding their inability to understand corporate structures, as well as never answering how or why a MITM companies' SDK ended up being embedded in their app. Further, even in times of stress, lashing out isn't the best decision. If I were interrogated by a cop and I called them a bunch of names, I would attract additional charges, on top of being suspected of commiting the crime that I've been accused of.
- dcow 4y agoShe didn't lash out, everyone else did? She made it very clear numerous times that she didn't think the forum appropriate for discussion of speculation.
- tambourine_man 4y agoTo the brave souls that have read the entirety of this novel, could you please provide a TLDR? Thank you.
- occamrazor 4y agoTrustcor is apparently connected with a spyware/malware company. Trustcor denied that,but didn’t convince Mozilla and Microsoft.
- zchrykng 4y agoOr anyone with a couple brain cells to rub together. I mean, sure, they might not be related and this is all a huge misunderstanding, but CAs should be trusted beyond any doubt and Trustcor isn't even close.
- Nurw 4y agoMy best attempt at a TL;DR: TrustCor had some connections to an app in which the android version contained spyware. They claim it was placed by a malicious previous employee, no name given. But a recently deceased key founders son was heavily involved with the company that made spyware. I think TrustCor's claim is that the son was only an investor in both firms and therefore had no direct involvement. This seems to not be the case, he is listed as "Key Principal" in a directory-entry about the spyware-company and the person is also mention as an employee of TrustCor in the emails.
- phpisthebest 4y agoWe still do not resolve the root of the problem... the fact we needs CA's in the first place
- olliej 4y agoWhat is your proposed alternative?
- phpisthebest 4y agoTACK [1] or Convergence [2] are two proposed solutions, though convergence seems to be dead [1] http://tack.io/ http://tack.io/ [2] https://en.wikipedia.org/wiki/Convergence_(SSL) https://en.wikipedia.org/wiki/Convergence_(SSL)
- XzAeRosho 4y agoBoth are basically dead. The draft for TACK was made in 2013[1] and their mailing list doesn't even work[2]. [1]: http://tack.io/draft.html http://tack.io/draft.html [2]: https://lists.riseup.net/www/info/tack https://lists.riseup.net/www/info/tack
- jiggawatts 4y agoAs others have pointed out, CAs are 100% superflous to the existing DNS registrar and delegation system. All CAs do is verify that you "own" a DNS domain, which is precisely what DNS registration sets up in the first place. Registrars should be Root CAs handing out subordinate CA certificates with every domain they issue, scoped to that DNS domain. This will never happen, because companies like Verisign have billion-dollar vested interests in it not happening. Technically it makes perfect sense, but the leeches collecting rent on the Internet don't want to let go.
- account42 4y agoDNS registries already hand out signing certificates, just not for TLS certificates but for DNSSEC. DANE bridges the gap. It works today (*). (*) In supporting clients, conditions may apply. I'm not sure what kind of pull big cert has that could allow them to stall DANE adoption. Sure, VeriSign acts as both a CA and a registry for the big domains - but they don't own those domains.
- testplzignore 4y agoOriginal request to be added to the root store: https://bugzilla.mozilla.org/show_bug.cgi?id=1231853 https://bugzilla.mozilla.org/show_bug.cgi?id=1231853 Public discussion: https://groups.google.com/g/mozilla.dev.security.policy/c/0g52YKDvvT4/m/A6VKJzkVBAAJ https://groups.google.com/g/mozilla.dev.security.policy/c/0g... https://groups.google.com/g/mozilla.dev.security.policy/c/R2uG3wisU7s/m/ie_v7RHMBwAJ https://groups.google.com/g/mozilla.dev.security.policy/c/R2... I would be interested to hear others' thoughts on if this process was sufficiently rigorous.
- ShroudedNight 4y agoAsking as an outsider: what responsibility should the Trustcor related "Neil Dunbar" carry in all of this?
- loeg 4y agoCompare: https://bugzilla.mozilla.org/show_bug.cgi?id=647959 https://bugzilla.mozilla.org/show_bug.cgi?id=647959
- Genbox 4y agoThis is great. Gave me a good chuckle.
- nixgeek 4y agoThere was another thread here which I haven’t seen anyone mention or cite yet: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/5dqLlvAXOgw https://groups.google.com/a/mozilla.org/g/dev-security-polic...
- shkkmo 4y ago> The most recent attacks against us involved the creation of companies in the United States very similarly named to those of our shareholders (which have since been dissolved). We believe those may have been used in an effort to do something cyber-physical however our only evidence of that has been an attempt to gather more information about our company through insurance inquiries by these companies (which were caught and stopped). This particular claim is the most interesting. If true, it would be a big story, and if false, it seems like it would open up fraud charges against Rachel.
- dcow 4y agoI hope TrustCor takes WaPo to court for libel. That's what needs to happen in situations like this.
- zchrykng 4y agoYou are aware that Truth is an absolute defense against libel, right? TrustCor would have to prove that WaPo acted with actual malice to get anywhere with a suit.
- AnimalMuppet 4y agoDepends. The goal of a lawsuit isn't always to win the lawsuit; sometimes it's to generate publicity (and will then be quietly withdrawn later).
- thinkingemote 4y agoWith so many small servers using noip.com and noip.com using trustcor what are the potential implications for this service or for their users?
- Ajedi32 4y agoIs this the first time a CA has been distrusted for reasons completely unrelated to the security or operations of the CA itself? Reading through Kathleen's summary of the issue[1] that others linked elsewhere in this thread, the only statement relevant to the actual CA portion of TrustCor's business seems to be: > There is no evidence of TrustCor mis-issuing TLS or SMIME certificates. Even the original post says: > Just to restate: I have no evidence that Trustcor has done anything wrong, and I have no evidence that Trustcor has been anything other than a diligent competent certificate authority. So it seems like the sole basis for this action is TrustCor's mere affiliation with another company that does TLS interception? If that's true, it seems like a pretty significant departure from previous removals, which all (to my knowledge) involved some sort of action or inaction affecting the security of the CA certificate itself. Is there anything in either Mozilla or Microsoft's root store policies which prohibit CAs from being affiliated with shady companies? Or does this just fall under the "at our sole discretion" clause? [1]: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/yLohoVqtCgAJ https://groups.google.com/a/mozilla.org/g/dev-security-polic...
- samb1729 4y ago> So it seems like the sole basis for this action is TrustCor's mere affiliation with another company that does TLS interception? The CA representative was presented with the challenge of proving their CA should be trusted, and failed it. This isn't a case of "presumed innocent until proven guilty" as in a criminal trial, so looking at it through that lens isn't very helpful. I think it is reasonable to conclude from Rachel's communications that TrustCor cannot be clearly identified as a trustworthy root CA, and thus they have been removed.
- Ajedi32 4y agoMaybe that's a reasonable standard, but if that's what they're using now it's still pretty noteworthy, since like I said I can't recall any instance of a CA being removed for that reason before. In the past there's always been some sort of egregious security issue that calls into question the security of the CA certificate itself.
- 4y ago
- Kukumber 4y agoGood thing that i do not trust both Microsoft and Mozilla myself already
- advisedwang 4y agoI think what's missing here is that TrustCor has no "right" to be included as a root CA. The question to ask is: is it in the interest of the browser's users. TrustCor is some (smallish) risk for basically no gain, so the conclusion is is to remove it as a CA. This sucks for TrustCor. They may have done nothing wrong. That doesn't matter.
- camkego 4y agoI believe I've seen comments from crypto experts saying that it was a mistake to put authentication and identity in TLS/SSL. I'm not sure I understand the alternatives... But has this been developed further somehow by the crypto/security community?
- deleted 4y ago[deleted]
- dumpsterdiver 4y agoThere aren't many other things that I take more satisfaction in than watching a bad CA get spanked. This made my day.
- USA-ME 4y agoTRUSTCOR employee NOT having authorization to sign root certificate did it and got the auditor in trouble. I am trying to get the CFO to explain to him YOU cannot let his secretary issue certificates with no EXPERIENCE.
- USA-ME 4y agoMY COMMENT BELOW