Mozilla, Microsoft yank TrustCor's root certificate authority
washingtonpost.com
washingtonpost.com
https://groups.google.com/a/mozilla.org/g/dev-security-polic...?
https://groups.google.com/g/mozilla.dev.security.policy/c/Me...
Mozilla: There are some misissued certificates. Revoke it.
Japan: Nah, you can trust us. We are government. It will expire soon anyway.
Mozilla: That's not an acceptable response. We do not trust you. Have a good day.
Japan: Wait. We will revoke. Just kidding. Please trust us.
Mozilla: Too late.
Lol
oh lawd.....
Have you dealt with public sector before? That's essentially status quo across the board.
Surveillance:
https://theintercept.com/2018/05/19/japan-dfs-surveillance-a...
https://www.nytimes.com/2022/02/02/business/japan-elderly-su...
https://giswatch.org/en/country-report/communications-survei...
Cybersecurity:
legal framework - https://iclg.com/practice-areas/cybersecurity-laws-and-regul...
policy - https://thediplomat.com/2022/09/japan-needs-a-cyber-ministry...
Writing small novels in response to simple questions ("who owns the company", "in what countries are you a legal entity") was never going to work with the CA forum. It might work in corporate contexts where nobody has the time to read emails, but it only seems to have raised suspicions more in this mailing list.
When Serge Egelman came up with a plausible defence for why both the allegations and the responses to them could be true at the same time (the representative and the current employees actually being victims of a company set up in bad faith and left behind by government/bad actors) she becomes extremely defensive. The thinly veiled accusation of sexism definitely doesn't help their case at the very least.
I find this a very strange response by a CA representative, or a CA in general. If the company is actually the victim of something bad, it can definitely learn a thing or two about clear communication. I do like the way the paragraphs of her email was structured (in response to, prior context, actual answer), though.
Imho, Matthew Hardeman makes the best point in the entire thread:
"Something that yet again concerns me in this discussion is an issue that I touched on previously in the discussions related to Dark Matter: that unless the program is requiring transparency as to corporate governance and management/operations authority, and establishing a basis for trust and accountability at the level of those individuals empowered by participation in the program, I believe we will continue to see these subjective trust decisions again and again. [...]
I once again humbly submit that I believe the executive and operational management teams of the CAs in the programs should be required to submit to the root program personal attestations as to their position and authority along with a commitment to inform the program promptly if anything has altered or replaced their authority. I believe there should be an explicit understanding that failures by such person(s) would be held against such person(s) individually and would bar their involvement at other trusted CAs for an indefinite period.
I yet again advocate for a measurable standard for holding CAs accountable at the executive management / operations level with costs taxed upon those persons who have made commitments to the program and failed to honor them.
It seems likely to me that one or more presently included CA could be reasonably described as owned by Blackrock or Vanguard. [...]"
That would upset far to many balances/be way too hard however.
I honestly feel like his explanation is likely, but she was in complete denial knowing how she's effectively left holding the bag.
Is she and the company now in a better place having everything revoked but still standing by her assertions? or would it have been better accepting the possibility of what happened and instead tried to work with everyone involved?
Serge was giving her rope to pull herself out of this hole and she just seemed to want to wrap it around her own neck instead...
>Unknown until recently by any employee officers of TrustCor we and Measurement Systems S de RL had in common a group of investors who represented funds (groups of companies and other funds), not individuals. Even though we shared a common group of investment funds, we have always operated our business independently of any other company and have exclusion provisions in place to protect the CA business from having access-to or being controlled by or influenced from any third-party, investors, equity-holders, or anyone other than TrustCor’s CA Approving Officials and employees. To the best of our knowledge (and our focused investigation) there is not and has never been shared ownership with any defense company or any USA company. This common group of investors with Measurement Systems S de RL. had already dissolved mid 2021, before these recent claims were publicized, meaning as a natural course of business and not as a reaction to any claims or adverse events. In 2021 TrustCor ownership was transferred from the initial investors/founders to the employees of TrustCor. The legal process has been very step-by-step and very slow, especially due to the protracted treatment and recent death of one key founder, Ian Abramowitz. Nonetheless, it is underway and irreversible, and the common investment vehicle was dissolved over a year ago.
I'm not sure how that isn't a straightforward answer to a somewhat complicated situation in transition.
Don't fault a person for giving a comprehensive answer when you ask an important but complicated question.
If people knee-jerk from that, that's a listener problem, not an answerer problem.
As a CA, even a hint of malfeasance should require in depth transparent answers. Not this legal BS peddling.
Because from what I read, I could see a decent chunk of them getting tossed out at the end of the star chamber as well.
And then we'd be left with a more centralized system with a few large players.
If corporate structure, ownership, and governance is important (it is!), then there should be standard processes, not ad hoc lines of interrogation whenever a CA happens to be noticed.
The CA system is already designed like a centralized system where the operators (CAs) have full privileges. Adding another CA just means adding another potentially malicious or vulnerable single point of failure that could bring down the whole system.
Kathleen obfuscates it a bit by putting the name of the director in a footnote, but here it is put together:
> The same individual was responsible for the day to day operation of both TrustCor’s CA business and MsgSafe. They are listed on TrustCor’s website as the VP of TrustCor’s CA operations and the Director of Operations for MsgSafe. [2]
> ...
> [2] Rachel McPherson is listed as the Vice President of Operations, having “access-to and control-over the CA and CA Business Operations” in a company document submitted privately by Rachel to Mozilla. Press releases on TrustCor’s website list Rachel McPherson as MsgSafe.io’s Director of Operations, e.g. https://web.archive.org/web/20221108224150/https://trustcor.....
1. Graduates 2007 with bachelors in media arts
2. Office admin 2007-2009
3. Volunteer coordinator at cancer foundation 2009-2013
4. VP of ops at trustcor 2013-now
That is ... an interesting career trajectory to be sure.
It looks like Trustcor was maybe founded in 2013, so maybe just the typical startup "here have a VP title" type thing, but yeah
It feels like all the people swayed by this have never worked for smallish shady clusters of companies or with them, and it shows.
> Based on that understanding (and again, please let me know if any of that is incorrect), I personally believe it's possible that Rachel may be a victim here, if she really is the primary TrustCor shareholder (e.g., maybe the company was given to employees, after it was no longer useful). If TrustCor's private keys were compromised at its founding or before (e.g., so that Packet Forensics could sell TLS-interception boxes), the company itself would have little continued value, so long as it passed its audits (and remained trusted by browsers and operating systems). It's therefore possible that Rachel had no awareness of this, and as a result is in the denial phase of realizing that she's the victim of a scam. This is not a statement of fact, I'm just offering it as a possibility.
(Rachel vehemently denied this)
Are root cert keys not rotated?
In effect, no. Such a "rotation" requires all clients trust the new root. Your PC probably gets software updates every week or every month, maybe your phone gets one a month or per quarter (until support runs out). But how about your smart TV ? Car ? Internet-connected Doorbell ? That IP phone you disconnected last winter and forgot to re-install ?
Big CAs tend to ship new roots periodically, in addition to their existing roots, so as to begin gradually phasing over, over a period of several years. So e.g. HugeCA mint a new key in 2001, the major trust stores decide to trust it in 2002-2003. In 2005 HugeCA offer certificates from the new root to customers who prefer the new root and understand the risk. Unfortunately these customers see high failure rates, e.g. the all-in-one printer scanners from a big name company they used in their offices have firmware last updated in 1998. In 2008 HugeCA confirm the big name company printer/scanner firmware update is complete and begin in 2009 selling these certs more widely, there are a few hiccups, they don't work in Windows ME which one customer insists is "the latest version". But maybe by 2011 HugeCA can announce retirement of the old CA root with a retirement date of say 2015.
Some older clients unfortunately can get into a state where they distrust root #1 (e.g. because it is old) but they know it exists, and so even though they trust root #2 they can see this alternate path via the intermediate to root #1 and reject the whole mess. People shouldn't write software which does this, but they did.
For example, the DigiCert Global Root CA in HN's cert chain is valid from 2006 to 2031.
They are but by their nature as core components of OS and devices they have to be long-lived, because they “bound” the lifetime of their sub-certs.
So root-certificates usually have an expiry of a decade or two, intermediate certs a few years (about 5), and then leaf certificate lifespans have been cut down drastically: used to be you could get a 10 years cert, then the CABF cut that down to 5, then 3, then 2, and I think now it’s a year (plus a one month grace period, so 13 months), and some registrars issue much shorter certs than that, notably Let’s Encrypt which issues 90 days certificates and basically requires automation.
Which massively reduces expired cert problems. If you only need to do it once a >=year you do it manually and at some point someone forgets / the guy with the calendar reminder leaves...
If you have to do it every 2-3 months you automate it with alerts for when it fails.
Thus positively confirming that she was in the denial phase.
Also, they tend to be overly verbose but with no real substance as to waste everybody's time so it might look it was GPT-3 instead.
Anyway I'm not claiming it _actually_ was GPT-3, rather that it similarly lacks substance. It's instead creating an illusion of content with words.
That is not incriminating, that is standard practice: say the least amount possible unless compelled by the law, because even benign things could later be used against you.
Corporate legal counsel often doesn't share the reasoning behind their advice for this very reason.
> MsgSafe offered this app (with the malware SDK) to the public via the Google Play store as part of a public beta, where it was free for anyone to download up until earlier this year. MsgSafe publicized its mobile app on social media. As of this writing, MsgSafe's website still links to the Google Play store (though the app was removed earlier this year):
>> This is not correct. The MsgSafe.io beta app was actually a testing beta, which could not be accessed by anyone via the Google Play store. The only way the app was accessible was to our employees or via a unique social media link MsgSafe.io sent out over 3 years ago, and that link only worked for a limited time. Using that unique social media link, we can tell that less than 1/10th of 1% of MsgSafe.io's users would have had the opportunity to download to test the app, and the actual number that installed it was much lower. Also, your statement about the MsgSafe.io website still linking to the Google play store is completely false. Did you even check this before making this post? In the screen-shot you shared, the icon labeled "Download on Google Play" does not direct you to the Google play store, it directs you to https://www.msgsafe.io/android which actually takes you to a 404 page on the MsgSafe.io website - it never leaves the MsgSafe.io website. Had you hovered over this link you would have seen this. Of course we're not proud of an outdated website and this should be updated, but that doesn’t make your false claim true.
As of November 10th 2022 it still redirected, the IA Wayback Machine cached it: http://web.archive.org/web/20220701000000*/https://www.msgsa... (Direct link to Nov 10th http://web.archive.org/web/20221110070138/https://www.msgsaf...).
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?
Still, as pointed out in the email thread, a CA is also evaluated on how trustworthy they are in a broader sense than the baseline requirements. Uncertainty and doubt is great at making people dizzy and muddying the waters, but compared to other CAs who respond with openness and transparency, the contrast is striking.
What starts as a relatively boring thread morphs into something else as it goes on.
I have to say though, I did not read all the responses from the accused, as that is essentially impossible.
The other half of her text was her answering questions that were never asked.
At no point did she answer the questions that were asked.
She was repeatedly asked about the corporate structure and shared investors. The answers reached from claims that it'd be too much content to summarize in this forum, claims that lawywers advised against it, claims that answering truthfully would lead to tax obligations, to claims that she doesn't know and would have to speculate.
Instead, she spent lots of time explaining the remote-work arrangement in Canada (irrelevant), the upstream networks of their Phoenix datacenter (irrelevant) or the tax situation of employees/contractors working for their company (also irrelevant).
To be clear: if you don't know the answer, it's not evasive to say "I cannot answer that" or "I don't know the answer" or "giving an answer would be speculation on my part".
Or not being a company who derives the majority its revenue from the company above?
This whole controversy is like a flock of lambs asking a pride of lions to stop some mosquitoes from biting them.
And it seems like Mozilla's concern is: "Is it in Mozilla's users interest to have this CA in their trust store?", which is probably the only sane way to run a trust root program. That means any concerns about the well-being of the company which runs the CA must be ignored.
* TrustCor owns MsgSafe.io, which somehow incorporated an unobfuscated and customized version of the malware. She kept trying to distance the CA from MsgSafe, but as Kathleen points out that's disingenuous given that Rachel herself is both VP of Operations of the CA and Director of Operations of MsgSafe.
* TrustCor was, until recently, owned by the same holding company that also owned Measurement Systems, which produced the malware incorporated by MsgSafe's app.
If these things were not true, they should have been pretty easy to debunk. If they are true, I agree with Mozilla that they provide sufficient reason to revoke the CA. The ties to the malware are just too close to risk leaving them trusted.
An example is the bit of boilerplate that kept repeating how the app was BETA and could only have gone to a small percentage of people (not relevant), and it wasn’t ever “published” (which is a lie) and how sdks get updated all the time and it is not our place to speculate about how that might have happened. This is an extremely abridged version of this “argument” that she trotted out repeatedly just trying to tire people out. There are many other examples of this type tactic in her responses. The overall effect is that she very much appears to be arguing in bad faith.
Those were clear questions.
I read it all, it was extremely repetitive with little substance. When she did say something new/interesting it was cagey and often not direct.
> She may be partly to blame for that, but people asked for answers and didn’t read them when given!
Disagree. They read it and ignored the fluff that said nothing of value.
> I don’t think TrustCor’s situation is something to joke or gloat about. Someone’s entire business just got ruined because of, if Rachel is to be believed, something wholly unrelated to operation of the CA and arguably entirely out of their control.
And that's the thing, she isn't to be believed, I sure as heck don't believe her. I posted in another comment a clear lie about linking to the android app (not to mention the constant "It was never in released" BS is so mealy mouthed it isn't even funny). The same parent company owned the CA and this msgsafe, it also seems clear there was a little more to the "Measurement Systems" relationship than Rachel would admit. Sorry, that's way too many coincidences. The final nail in the coffin is the ties (even if they are fragile) to Packet Forensics which you wouldn't want in the same breath as CA yet the connections are hard to ignore given everything else Rachel said (or didn't say).
I also don't for a second trust all the:
> I was reminded by some of you this is a big public forum with non-CA-operators and non-browser/platform-developers present, and that participants have a lot of interest in these topics but not always the same level of experience or familiarity with the CA operations and root CA program guidelines or technical knowhow as the intended audience. Therefore let me begin by saying THANK YOU to my fellow CA/B Forum members and members of the larger community for reminding me of that, and separately thank you for those of you that have sent very nice and encouraging, supportive emails (you know who you are)
Yeah, my girlfriend goes to another school, you've never heard of it... Okkkkkaaayyy.
Then look at their "Why are you persecuting us!" line about other CA's, which just screams guilty. On top of all of that their msgsafe system appears to be a fraud (it's not E2EE despite their claims) so if they are acting that way with one arm of their parent company why should we trust the CA (who's auditor looks questionable and also the fact they've used the same one every year)?
The phrase you are really reaching for here, well-known to every truly ancient netizen, is "the lurkers support me in email".
Some unhinged usenetter (but i repeat myself) traced its origins to the mid '90s: https://groups.google.com/g/soc.singles.moderated/c/UTopjdXT...
And, as mentioned in that poast, there is a song: http://www.jowaltonbooks.com/poetry/whimsy/the-lurkers-suppo...
Concerns about Trustcor - 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 - Nov 2022 (3 comments)
Mysterious company with government ties plays key internet role - https://news.ycombinator.com/item?id=33519020 - Nov 2022 (2 comments)
Also browsers should display a warning when a certificate issuer for a website changes.
What you are proposing is an attempt at solving an entirely different problem that is, furthermore, largely orthogonal to ensuring the integrity and confidentiality of Internet traffic. It would be nice if that problem were solvable, but every time the Web PKI flirted with that it ended horribly[2]. (And now the EU authorities are trying to force it anyway, it seems[3].) Ensuring your bytes end up on the host you named, intact and unsnooped, is a comparatively easy problem that’s also pretty meaningful, and it seems smart to restrict ourselves to that. (I’d have advocated for DNSSEC+DANE instead of CAs, even, if I had any confidence at all in the DNS registrars’ ability to handle key material and willingness to give up domain control when that ability fails.)
[1] https://arstechnica.com/information-technology/2017/12/nope-...
[2] https://www.usenix.org/system/files/sec19-thompson.pdf
[3] https://scotthelme.co.uk/looks-like-a-duck-swims-like-a-duck...
That is, am I simply being phished in private or is the government also listening to me being phished?
It's trivially easy to solve the second problem and it doesn't require any PKI infrastructure whatsoever and we delayed secure transport by decades by tying it to the generally less-useful question in #1.
There are few entities online I trust more than I would trust someone impersonating them: basically only if money is changing hands. But I don't need to know that e.g. ycombinator.com is actually ycombinator.com because I don't trust ycmonbinator.com any more than I would trust someone impersonating ycombinator.com.
And then you find out there are ways to convert a passive eavesdropper into an active attacker (remotely injecting packets to manipulate the TCP connection state, based on observed sequence numbers), and the distinction becomes a bit fuzzy...
In this context it’s funny that https://satan.com redirects to https://mybible.com.
But I agree with you on the sentiment that stopping snooping technically is the easy part and this is already possible today with Public Key Pinning, DNSSEC, client certificates and so on.
But that's why I think the role of the CA should change so that the signatures actually gives some form of tangible trust that people can relate to.
But this is a tough thing to do. The best way to do this would be to introduce a new type of certificate, that can be stapled onto web requests maybe (eg. a signature at the end of the http body), that isn't controlled or authenticated by any existing system. This would allow clients to implement this system based on merit and based on whether or not it solves problems and concerns these clients have. For example, if it's literally just EV certificate boogaloo[0], then Chrome can choose to not implement it.
But when you try to force it onto people in the form of QWACs or what have you, and have it government-mandated, this goes against the theory of 'open source' standards being adopted because they're a good standard, and instead degrades user experience by forcing client vendors to implement them regardless of their flaws.
0: https://scotthelme.co.uk/the-power-to-revoke-lies-with-the-c...
What we should do is to delegate the few CAs that legitimately do non-domain validated certicates for specialized applications to only this. That includes things like signed code. Things like extended validation was invented solely to print more money and should be phased out of web browsers. They are not "more secure" and should not be regarded as such in any user interface.
The parties to issue domain validated certificates should be the domain registries. They do their job reasonably well already. They are already tasked with issuing domain ownership. It is only natural that they should validate this ownership cryptographically as well. It is a trivial extension to their business, and the registry/registrar model can be kept intact.
The trust chain for a domain validated certificate today includes both the registry and the CA, and either can fail. The risk is strictly minimized by removing the CA from the equation. CAs provide no value to the end user.
You will find several high profile people arguing against this. Do note that every one has vested interest in the status quo, either directly or indirectly by having CAs and governmental agencies as their clients.
How do we change this system? Mozilla has by way of their history some weight in these matters, and several capable people on board. It is my intense hope that they have a long term plan. Let's Encrypt is, as great an achievement as it is, still built on a broken trust model. But it could also be an excellent beachhead into a strictly better trust model for the end users.
For example, Azure's Key Vault has built-in certificate issuance automation capability, but only with two for-profit CAs: DigiCert and GlobalSign.
Why not Let's Encrypt?
Because there's no margin on free.
I think it would be great if something like EV certificates were available from national governments.
We have pretty solid digital ID support in Austria, but all the tech for signing and authenticating documents (useful for invoices or account statements) require special software, and aren't built into web browsers and email clients that people use.
It would be nice if I clicked a link in an invoice email, if I could check that aws-billing.at is indeed a domain that belongs to "Amazon Web Services" registered in Austria or if it is a phishing attempt from a script kiddie in a foreign country.
For domains this assumption been proven wrong in practice several times. There are too many issues with almost identical names, or names that merely look identical but aren't, or just the difference between "Amazon Web Services Inc." in two different jurisdictions.
Troy Hunt has made several long blog posts with some convincing real world examples.
It is easier for end users to see which is more reputable of "amazon.com" and "amaz0n.biz", than it is to value "Amazon Inc." against "Amazon Cloud Services". It is not that the CAs are doing a bad job. It's that domains are the identity we really care about.
Furthermore, I am of the opinion that CAs should be destroyed.
I think it would harm users relying on certain sites. This already happened with CNNIC and .cn, so I don't think that mandatory restrictions would make it better (and besides, the only CAs which voluntarily ask to restrict issuance to certain TLDs are government CAs).
Care to elaborate? I don't really understand how it harms users.
Also to clarify: restricting it to specific TLDs where the CA physically operated would amplify local laws, while restricting it to TLDs that are outside the CA's physical presence would basically mess up enforcement and would spur governments to curate a mandatory sanctioned list (heard of EU QWAC?) It's a lose-lose case either way.
I don’t understand the “amplifying local law” part. How is restricting the power amplifying?
That's not an example of limiting CAs to certain TLDs; that's an example of limiting certificate users to a single CA. I'd sooner use a self-signed certificate than one signed by a monopoly government-controlled CA.
Still, the name constraints extension, which restricts all certificates (transitively) issued from a given CA to a given DNS subtree, has been in the “Internet profile” of X.509 (PKIX) since the December 1996 draft[2]. The problem from this technical point of view is that very few implementations supported it until a couple of years ago[3].
[1] https://medium.com/@sleevi_/x-520-whats-in-a-name-da6ea8954b...
[2] https://datatracker.ietf.org/doc/html/draft-ietf-pkix-ipki-p...
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.
Netscape invented all this stuff in the 1990s as SSL. Turns out you need a PKI to make it work, because of a tricky edge case which otherwise makes the whole thing worthless. So, they used the existing but little used X.509 PKI left over from the X.500 directory work, even though the Internet is not part of the envisioned global network X.500 is for. The X.509 PKI had a bunch of famous brand "trustworthy" companies minting certificates.
PKIX, an IETF working group to figure out how to force X.509 to be suitable for the Internet, adds stuff like SANs (Subject Alternative Names, a way to express Internet ideas about naming like IP addresses and DNS names) but that all happens after SSL 2.0 and SSL 3.0 and people start writing https URLs.
This flexibility is what allowed let’s encrypt to bootstrap, right?
Obviously, that broke down over time, and nefarious actors (both governmental and private) popped up.
Peer-to-peer? That would require you to constantly monitor the activity of those peers and update your lust of trusted certificates.
Singular trusted entities like browser or OS vendors? We already have that. Browser/OS certificate list are currently the entry point and have even higher priority than root CAs -- that is what the article is about.
Government bodies are an easy-to-go "trusted" entity because, while you may or may not actually trust them, you are forced to "trust" them in many aspects of daily life anyway. You are forced to rely on the fact that the police doesn't randomly knock on your door and arrest you. Governmnent bodies may (depending on your country) simply demand higher taxes than you owe them, and you have to fight a lawsuit to avert that. Government bodies can easily falsify evidence that makes you lose your house because it now says that somebody else is the owner (lawsuit again).
Basically, establishing trust in a matter of "I am actually talking to the legitimate server behind example.com and not a MITM" is easy, that could be solved by DNSSEC and cert pinning (although for legacy reasons, we went with CAs as the middle man).
But the really interesting thing, which is unsolved to date, is making sure that when you type "bank.com" in a browser, you have some sign that you are actually talking to Bank LLC and not some other entity.
In ye olde times, you didn't have to worry about someone else spoofing the domain name of "bank.com", e.g. as "b4nk.com" or "bänk.com", for one because access to registering domains was complex and expensive, and for one because criminals hadn't found out they could make money...
This would be better solved if the URL as a middle step did not exist can I could directly select Bank LLC. Right now we rely on google to shield us from domain name spoofing.
But then, unless we exchange keys with an entity beforehand (1), how can I even express that I want to visit that entity's website? Let alone solve the spoofing problem. We have to delegate trust to search engines, browser built-in lists, governments, company registries, whatever.
(1) possible, but only works if you know in advance that you want to communicate with a specific entity. Like before opening a bank account. I does not help when you don't even know which banks make an offer you are interested in.
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.
"is an incredibly sophisticated and sufficiently complex system with many components."
towards techies of Mozilla, Google and Apple.
> Upon further investigation into our domains and with additional information from our legal team, we have found that TrustCor acquired the DecoyMail system many years ago as the basis of our MsgSafe.io product and service. First available in October 2000 (over 22 years ago), the DecoyMail product (and its successor, our MsgSafe.io) is an incredibly sophisticated and sufficiently complex system with many components. A single component of MsgSafe.io allows domain names to be conveniently purchased through the software’s web interface which triggers a backend domain-registration 'register' mechanism that is pointed to an API or registrar account.
Did you mean to write, "easy to verify, and hard to game."?
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".
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.
Based on that, it seems like the "rebuttal" is trying to rebut irrelevant things, leaving the undisputable elephant standing in the room. (I admit I haven't read the entire wall of text.)
> I suspect the outcome would have been different if this was handled in a court of law.
If it was a criminal court trying to prove something beyond reasonable doubt, certainly. For a CA, it's the other way around, there needs to be strong evidence that keeping the CA is beneficial to the users.
But in a process sense, I am left wanting. I still don’t know what damage was done and why TrustCor CA got this special treatment in the first place in any way material to their CA issuing business, which they appeared to put great effort into operating by the books.
But, if I read correctly, Rachel claimed that there was no longer any shared ownership and tried to explain that ownership in the sense that the word was being use was not a correct term in the first place. I believe she said it was a shared incorporation services / legal council / investor, at most, and that the speculation as to that relationship conferring any authority pertaining to the CA’s operations was entirely incorrect since the executive authority had long since been signed over to actual company officers.
She failed to reasonably and convincingly refute some allegations. There were repeated requests to provide information, some of which would be trivial to produce if acting in good faith.
After reading the exchange, I (as a reasonable bystander with no material interest in either side):
* Don't understand the relationship between TrustCor and the malware distributor in a clear way that company ownership records would provide
* Take it as a false statement that the mail service doesn't have apps, as its website advertises them
* Don't understand how their auditor audited them when they don't appear to have a presence in Canada that would be factual based on the extracts from the auditor findings
Unrelated to her responses, I could take in on faith that a rogue developer added spyware from a company with the same owners, but the finding that the payloads were send to TrustCor servers diminish the acceptance that sufficient controls exist in the company to not question the security of them as a CA.
Combining that with basic questions about how exactly ownership changed that were never answered and instead obfuscated behind reams of "nothing speak".
The final basis for the determination seems to be that the main loss of from distrusting the TrustCor CA was thier sibling company's private email service that is, at best, advertising itself under a very shady definition of E2EE.
Thus this seems like an easy decision to me.
The interesting conclusion that follows from that is that if you are going to operate a shady CA, it behooves you to find some large clients to make cost of revoking your trust higher.
Playing devil's advocate: Why not? I mean yes, obviously if you end up in jail that might interfere with your ability to operate a CA (or any company for that matter). But barring that, as long as they haven't done anything to affect the security or proper operation of the CA certificate itself, why is that a basis for removing them from root stores? To the best of my knowledge this action is unprecedented.
"TrustCor CA got this special treatment"
I'm not a regular on that mailing list, any source that this is special treatment and other CA that are spyware software and snakeoil encryption software creators etc. are treated differently?
However, I think it's helpful to consider public comments separately from the responses of browser vendors. I think they did an admirable job of keeping the contents of their messages calm and focused on establishing uncontroversial claims. In no way are Apple or Mozilla's responses trying to make the person squirm, or trying to 'smell the guilt'. Mozilla's final assessment rests on TrustCor's quantifying value statement in light of the MsgSafe.io findings, i.e. the close tie of TrustCor operatives with this malware operation.
The legal system is hardly a panacea. Legal battles can be made to last many years. And a court of law has no ground to litigate on questions of trust in the first place.
The forum was able to establish a list of important and uncontested claims in a few weeks of strenuous discussion, and their assessment of the benefits of keeping TrustCor vs. the risks seems reasonable to me. Third-party inflammatory messages about Microsoft notwithstanding.
Which is why at that point you hire lawyers and a corporate communications agency to do this for you. When your company's existence is on the line, you don't want to do that stuff yourself.
The fact that her responses read like a letter written by a bad lawyer already violates that trust. She's saying as little as possible, admitting nothing, and constantly trying to evade claims on a technicality.
By behaving like they do and more particularly not providing any of the proof asked in the process, Trust is broken. They do not demonstrate they have their shit together, do not demonstrate they understand the process nor the problem, and in general shows they are not equipped in term of knowledge and skills to be a CA.
That they are guilty or not do not matter anymore at this point. They have failed at a more basic level of being a CA. They cannot do the things we expect a CA to do. Them being breached or using their power for bad things do not even matter anymore.
I usually have sympathy for privacy-friendly services being abused by bad actors, and i certainly have sympathy for anyone being impersonated by State-sponsored APT for nefarious purposes. However, after reading through the thread, this does not seem to match reality.
It took just a few email back and forth for TrustCor to change their statement from "we know nothing about these people" to "we used to have common investors", while placing the blame on a single recently-deceased individual... which still does not explain how a malicious data exfiltration (malware) SDK ended up in a beta product of theirs (a question they silently skimmed over), or why they pretend not to know why most of their legal infrastructure in place is deeply tied to this malicious actor.
Without commenting on the CA operations of TrustCor (and its lack of transparency), or the seemingly-broken security promises of the MsgSafe service, it seems relevant for the CA/B forum that TrustCor is obviously arguing in bad faith and trying to dissimulate ties to a now-well-known APT.
You would certainly expect most CAs to operate more transparently, to be registered where they actually operate, and to disclose where their hardware is located, especially when this location exposes them to NSL-style laws. Operating out of a mailbox in a tax heaven, for a company based in Canada, with machines in the USA is already very sketchy. TrustCor's responses in the mailing lists in my humble opinion clearly outlines that they are bad faith (if not entirely malicious) and should be treated accordingly by browser vendors.
I understand that Rachel is now in a bad position and feels smeared. And maybe she is not the person responsible for the malicious setup/activities of the entire company (maybe she's even unaware), but that's what you get for being the public face of a rather-secretive malicious actor.
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.
> Apparently it may also come as a surprise to some readers and the researchers themselves that other root program members are in fact international governments, and some are also defense companies, or companies who are wholly-owned by defense companies and/or state-owned enterprises, meaning "businesses" that are completely owned or controlled by governments. Further, some of those governments are not free/democratic and in fact some have tragic modern histories of basic human rights violations. We are none of those things and our company does not identify with those values. Given this point above, why of all potential targets are these researchers interested in TrustCor? They could go after countries with human rights violations that have placed a CA in the program.
I'd argue it could be termed "what-aboutism", but I personally fail to see how that matches my definition of "lashing out"...
This part in particular is what I would view as "lashing out"
I agree that it's "what-aboutism". In that regard, it does nothing to establish that TrustCor meets the standards for being a CA.
It does raise a good question for parallel discussion, though: Should Mozilla also be scrutinizing a whole bunch of other CAs as well?
That said, it appears mozilla's decision is founded not on their response in the thread, but on the fact that Trustcor basically is a root CA for the sole reason that they provide a useful service in the exact product being shown as untrustworthy. If the only reason is their email service, and their email service can't hold up to scrutiny (including promising e2ee and not actually providing it, and having poor development security practices) then why do they have root CA power in 99% of client devices? in my opinion, their email service didn't warrant such inclusion to begin with, even if the service was sound, and that's not accounting for their weird corporate ties (which may be legitimate, tbf).
And in practice, on the web you're baking SCTs into the certificates (technically sophisticated customers might buy certificates with no SCTs because they know what they're doing, but that's a speciality product, lotta people buy gasoline every day, but not too many need barrels of crude oil, if you claim 2 million distinct customers served daily but then say they're all buying crude oil I just don't believe you).
To get working SCTs the (pre-)certificate needs to be logged at one of a few dozen trusted Certificate Transparency logs. Which means there's a public record of every such certificate, who issued it and when it was logged.
While this is indeed not a court and doesn't have "Discovery" the CA agreements do require the CA to provide Mozilla and other vendors with complete records of certificates they're interested in, these days that is often provided in the form of crt.sh links because hey, the (pre-)certificates† were in the logs anyway, but it's compliant to provide the data as ZIP files or whatever -- if there is such data and you have it.
So, no, independent researchers can get a pretty good idea by just inspecting a public log view, and the browsers can insist on getting the exact answer if they want it, unless of course TrustCor doesn't care about being distrusted.
† You aren't required to log the certificate as well as a pre-certificate but in many cases CAs do that too. Modern rules are clear that the existence of the (non-working) pre-certificate is assumed to imply the existence of the corresponding certificate even if you claim the certificate was never actually issued.
> 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.
It's not some other company, its the same owners and operators doing malware under one name and running a CA under another.
EDIT: elsewhere in the thread someone linked the bugzilla request for TrustCor to be added. I had assumed that was a long time ago, but it's "only" 7 years ago.
When someone asks you what is the shared ownership of these two entities, and you tell a story about your summer in lancaster working in the mail room of one of the entities, it isn't useful or related to the question.
Its hard to tell from your repeated assertions that do not match what actually occurred in the thread. It feels like you skimmed, and have some bias attempting to give the benefit of doubt to what you see as the embattled party in some kind of unjust lynching instead of legitimate questions of entire shared corporate officer structures, and clearly shared dev teams [that the representative blatantly attempted to claim was out of line while avoiding the actual part of that evidence that was damning, that the dev somehow had access to the raw source of the library in question that very strongly indicates that it was their library and not the rouge devs'] of a known malware entity and a ROOT level CA.
If you are just trying to play devils advocate in what you feel is somehow a mob action instead of what is probably extremely conservative actions by some of the biggest and most legally careful entities in the planet then honestly, I ask why and for what purpose?
We no nothing. The whole exercise of the thread was to know something.
"Apart from our CA work, we also bought an aging email service with a few customers, and invested substantially in developing it into a flagship email security product line compatible with global email security standards including both S/MIME and GPG. Then, over the last few years we added unique features our customers demanded. Today it stands alone as a valuable email service enjoyed by millions around the world as an alternative to other popular web based secure email providers."
and unsubstantiated ad hominem attacks
"us recently by a biased group of security researchers "
Pushing the irrelevant BETA narrative
"TrustCor has never released a non-beta, public version of any mobile phone software/version and in fact the only mobile-friendly configuration we support is direct-from-browser mobile access that leverages the popular industry-standard framework for delivering near-app-quality mobile experiences using web browsing on mobile devices. You don’t need any downloaded software to use it whatsoever."
(where the still unanswered question is: Where did TrustCor get the source code of the spyware no-one else has?)
"Perhaps they are working with the US defense community, [...]"
Pushing unsubstantiated conspiracy theories that add nothing to the case
and on and on and on the same as before nothing new in that email.
That's on top of the technical and legal evidence of the companies basically being the same company.
The wall-of-text could be a result of unfair accusation, sure. No doubt she's under a lot of stress either way! And I did think that some of the accusations in the thread were a bit harsh, sarcastic, or otherwise inappropriate. But the facts stand.
See also: Ford Pinto
Instead of "tying to set guidelines" you can try to honestly answer the questions.
https://bugzilla.mozilla.org/show_bug.cgi?id=1231853
Public discussion:
https://groups.google.com/g/mozilla.dev.security.policy/c/0g...
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.
This sucks for TrustCor. They may have done nothing wrong. That doesn't matter.
"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"
"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."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.
> From a practical standpoint, Microsoft seems to have set the distrust date for TrustCor's roots to November 1, 2022 instead of November 30
> 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.
https://groups.google.com/a/mozilla.org/g/dev-security-polic...
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.
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).
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?"
- 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.
And if you do trust the connection to be free from active attackers then you don't need certificates at all, e.g. diffie helman key exchange would be enough to create a shared secret that in the presence of a passive adversary that can only observe.
But you've opened your bank account in person. When you got the token to login to the bank website they might as well ask you to sign their certificate since you are there.
Many banks do not require this. Many do not even have physical branches to visit.
I guess that's why you have a huge problem of people opening debt under other people's name there, which is a thing that doesn't really happen here.
* the people that run the Signal Servers (or whoever).
* The people that send the verification SMS.
* The phone company.
... even for a little while.
Two factor only verifies you, not the bank.
Also google's app doesn't easily let you export and backup the seeds. So you either remember to do that initially or breaking your phone == losing access to everything.
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.
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.
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/ 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.
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).
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...
If the certificate says "Company AB", nobody checks if that's true.
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.
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.
(*) 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.
[1] http://tack.io/
[1]: http://tack.io/draft.html [2]: https://lists.riseup.net/www/info/tack
One of many. Trusted root is ... funny.
I'm not sure I understand the alternatives...
But has this been developed further somehow by the crypto/security community?
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
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-identit... )
From the looks of it the EU wants to push out a wide spread identity management system, which is fine.
It's unclear to me after a brief perusal why they can't use a normal root certificate, or create their own along a letsencrypt line (indeed that would be a great benefit having another widespread free ACME powered certificate authority, one funded by the taxpayer), with the same protections and transparency as LE.
It's just a Farsi link to an English article that's automatically applying RTL styling, the original version of the page in English looks fine.
https://www.eff.org/deeplinks/2021/12/eus-digital-identity-f...
Such an extraordinary claim.
Are you able to provide any evidence that supports your claim that at any time the EU Commission tried to go "full police state", and that courts kept that from happening?
Right now Mozilla, Microsoft and many other privately owned root certificate mainterns control whether or not CA are trust worthy. I actually see your statement the other way around, it would be illegal for browser to support a CA when the EU deems it as untrustworthy.
You don’t pay a browser to get your roots included.
You file a bug report, and provide the supporting documentation and audits. If the relevant root program considers your supporting documentation sufficient, they include you.
You cannot pay a root program to include your root certa, and any CA that was found to have done so would likely find other programs considering that to be a red flag.
Three of the major trust stores are also OS vendors. Microsoft, Apple and Google.
Each of those three actually just has a rather opaque "send us an email and we'll talk about it" type process. I don't think there's any implication that you can or should pay them money (indeed Microsoft is clear that there is "No Fee" for this), clearly none of these organisations is desperate for cash. But it's actually unclear what you can do besides maybe send email and hope.
Mozilla's process is as you state to file a Bugzilla bug. You go in a big queue and there's eventually a public discussion on m.d.s.policy once you get to the front of the queue.
Now, in theory there is no relationship between Mozilla's transparent process and say, Apple or Microsoft. Indeed even for Google there's only a rather thin relationship, the final decision is theirs but they do say you need to talk to Mozilla.
But in practice the Mozilla process matters most.
For example: https://www.techtarget.com/searchsecurity/news/252436120/230...
Firefox seems to include root CA from the governments of: Hong Kong (so China?), Spain, Turkey, Tunisia, Netherlands.
The handling of key material is supposed to be checked as a part of the (required) yearly audits, which they have passed[1,2] (though the single auditor they’ve always used “does not audit any other publicly-trusted CAs”[3]). The links are in the Common CA Database (CCADB) [4], but it seems really hard to find a good publicly-accessible report page (I still haven’t found the older audits, for example).
ETA: For TrustCor specifically, Kathleen Wilson (responsible for the Mozilla root store) has collected the audit reports on Bugzilla[5].
[1] https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?at...
[2] https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?at...
[3] https://groups.google.com/a/mozilla.org/g/dev-security-polic...
[4] https://ccadb-public.secure.force.com/mozilla/IncludedCACert...
A thumbdrive in some safe, and a few printed-out copies of the key just in case the thumbdrive fails?
A separate company used an SDK which later was classified as malware and now TrustCor is no longer trusted. That is pretty unfair.
1. TrustCor operates "TrustCor CA" and "MsgSafe". TrustCor claims these are completely separate lines of business, but does not dispute that it owns and controls both of them.
2. MsgSafe incorporated a spyware SDK from Measurement Systems into their Android app. TrustCor claims this was done by a rogue contractor (and thus TrustCor had no control over it), and they also claim it wasn't a security breach (implying TrustCor allowed the contractor to do it). Also, MsgSafe claims to offer end-to-end encryption while demonstrably not offering end-to-end encryption.
3. Measurement Systems produced a tracking SDK that is now considered spyware. It has historically shared many high-level employees with TrustCor, including (allegedly) having the same CFO and CEO.
4. Vostrom aka Packet Forensics sells spy equipment that claims to be able to break HTTPS, like you'd be able to do if you had access to a root certificate. They have nebulous ties to both TrustCor and Measurement Systems.
5. TrustCor CA is no longer trusted because of the above, and because its VP answered questions about it by saying her lawyer advised her not to comment.
Which is something you could in principle do if you are a trusted root CA. But, this creates a smoking gun. The bogus certificate is a public document, you're always giving it to the client, and for Chrome, Safari, Chromium Edge you are also obliged to publicly log the certificate, where everybody can see it forever, in order to have an SCT (proof of logging) which those browser insist on seeing.
Modern rules require a root CA to disclose any intermediate CAs which are created, even if not currently in use (e.g. because still being tested) and which could issue trusted certificates unless the certificate for the intermediate is technically constrained (which is complicated, but a general purpose CA is not technically constrained for the purpose of this definition)
In practice, most outfits offering "MITM" type capabilities are for corporate environments, education, that sort of thing, where you can say "All employers/ students/ whatever shall trust our our private CA FOO" and then you can MITM using the trusted FOO CA. So this doesn't interact with the Web PKI overseen by m.d.s.policy at all. If you don't want to get MITM'd don't trust some sketchy private CA.
It's a choose only 1 sort of deal.
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.
CAs should be assumed guilty until proven otherwise.
That's not how things work. The role of a Certificate Authority is to act as a trusted third party. If that third party is unable or unwilling to demonstrate that they are trustworthy then naturally they can't be expected to assume that role.
There is a lot of doubletalk in the thread that is supposed to somehow lead us to believe that TrustCor CA and MsgSafe are totally separate companies, despite lots of circumstantial evidence that they aren’t.
It also happens to appear that MsgSafe and the company that actually created the malware (Measurement Systems) might be closely related and/or the same, owing to a lot of the same names on corporate documents (many of which names are shared with Trustcor and/or Trustcor CA), plus the extremely suspicious fact that the malware in question was only ever distributed elsewhere in obfuscated form, yet somehow MsgSafe seems to have an unobfuscated copy built into their app.
It’s also extremely odd that despite all the protestations about Trustcor CA and MsgSafe being completely unrelated, the Trustcor CA director of business operations has intimate knowledge of the source control, server configurations, and VM snapshots of the server that the traffic was being proxied through at MagSafe.
TrustCor doesn't actually dispute that MsgSafe is the same company as them. For example, here is a press release where they proudly announce they own MsgSafe: https://www.prnewswire.com/news-releases/trustcor-evolves-em...
Instead, what they claim is that these two parts of the business are operated separately. As in, MsgSafe doesn't run on the same servers as the CA. So if a "rogue contractor" adds malware to MsgSafe and it goes undetected for several years, that shouldn't reflect badly on the CA side of the business at all.
(TrustCor was so evasive about this that they seem to have misled most of the people in this thread, though.)
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-polic...
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.
In the past there's always been some sort of egregious security issue that calls into question the security of the CA certificate itself.
A single entity issuing TLS certs and also selling TLS MITM services is pretty obviously an enormous conflict of interest. If this isn’t spelled out explicitly anywhere, it should be.