Hello all, In order to further compile the observations that may warrant some response from TrustCor, the Apple Root Program would like to add some additional notes. We concur with views expressed below that the corpus of these observations lend themselves to reasonable doubt about this company’s ability to operate as a publicly trusted CA, and at this point believe it similarly reasonable to expect TrustCor to address the concerns raised herein.
Observations: The “Primary Market / Customer Base” field for TrustCor in CCADB indicates "TrustCor develops privacy protection services and issues certificates to its customers in support of such services.” This seems to indicate that certificate issuance is not the core of their business, but rather augmentative thereto. However, looking at their website http://www.trustcorsystems.com/ (which redirects to https://trustcor.com/), there is little mention, and nothing predominantly represented, of products or services aside from TLS and S/MIME certificate issuance. Especially in light of the report which started this thread and other observations shared since, this rather benign-seeming observation then prompts the question: What are the privacy protection services these certificates are being issued in support of? As highlighted elsewhere, the address TrustCor has listed on CCADB doesn’t appear to house TrustCor offices and instead points to what appears to be a series of retail outlets, including a UPS Store, as referenced in the related Washington Post article (https://www.washingtonpost.com/technology/2022/11/08/trustcor-internet-addresses-government-connections/). Where is the Ontario Headquarters of TrustCor, as referenced by the corpus of audit statements representing TrustCor? Looking at Ontario Business Records, it also appears that TrustCor Systems S. DE R.L. (the corporation listed on their audits) "ceased activity in Ontario" on December 31, 2016. There are other registered entities with the TrustCor name, but these other registered businesses appear to be unrelated to TrustCor CA. Thank you, -Clint > On Nov 9, 2022, at 5:10 AM, 'Ryan Dickson' via > dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> wrote: > > All, > > The Chrome Root Program is aware of the allegations against TrustCor by > AppCensus > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/1df04806-96e0-4660-858b-6d890e7eb6b1n%40mozilla.org?utm_medium=email&utm_source=footer> > and described in this > <https://www.washingtonpost.com/technology/2022/11/08/trustcor-internet-addresses-government-connections/> > Washington Post article. Chrome maintains a variety of mechanisms to protect > its users, and is prepared to use them as necessary. > > To be clear, behavior that attempts to degrade or subvert security and > privacy on the web is incompatible with organizations whose CA certificates > are included in the Chrome Root Store. > > The research by AppCensus, along with our own, has identified what could be > described as “coincidences” that, when compiled, could call into question the > honesty and security of a publicly-trusted root CA owner or operator. As > described by Kathleen Wilson > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/3f8c3118-929b-4212-b0ba-4310b59c9399n%40mozilla.org?utm_medium=email&utm_source=footer>, > we believe it is TrustCor’s responsibility to assuage community concern by > publicly addressing the questions outlined in her message. > > Additionally, we noted the following coincidences and request further > clarification from TrustCor: > > Coincidence #1 Audit Irregularities > TrustCor uses Princeton Audit Group (PAG) as its auditor. > According to CCADB records, PAG does not audit any other publicly-trusted > CAs. > TrustCor’s most recent audit statements ([Standard > <https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=c8857fc5-b201-4c4c-8717-f455b10ff5bc>] > and [BR - TLS > <https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=459d2155-e50c-4497-929c-ee8a57f77708>]) > describe CA operations in Toronto, Ontario, Canada. > PAG is listed as a licensed practitioner only in the USA > <https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/licensed-webtrust-practitioners-international#:~:text=PrincetonAuditGroup%2CInc>. > TrustCor’s CPS <http://trustcor.com/resources/cps.pdf> indicates the data > centers are located in Phoenix. > Though the management assertion references Phoenix, PAG’s attestation does > not. > Beyond [1 > <https://www.theinfostride.com/lbgloballaw-confirms-commitment-to-security-through-soc-2-type-2-and-soc-3-compliance/>], > [2 <https://www.gep.com/newsroom/gep-attains-ssae-16-soc-2-certification>], > and [3 > <https://www.yumpu.com/en/document/read/42020572/audit-report-management-assertions-and-system-webtrust>], > we found little public information specific to audits performed by PAG. > > Coincidence #2 WIPO Complaint > This page > <https://www.wipo.int/amc/en/domains/search/text.jsp?case=D2018-1096#:~:text=Investigations%20conducted%20by,clients%20or%20employees> > summarizes a 2018 complaint filed with the WIPO Arbitration and Mediation > Center against Trustcor Systems S. De R.L. by Compagnie Générale des > Etablissements Michelin, owner of BFGOODRICH. > The complaint cites concerns related to TrustCor registering > bfgoodrichpromotions.net <https://www.whoxy.com/bfgoodrichpromotions.net>, > and the risk of a related phishing scheme resulting from the registration and > corresponding email servers configured on the disputed domain name. > Ultimately, the Panel found TrustCor’s passive holding of the disputed domain > name indicated “bad faith”. Furthermore, the Panel also found that TrustCor’s > failure to respond to the Complainant’s cease-and-desist letters was an > additional circumstance evidencing the TrustCor’s “bad faith”. > This type of behavior is consistent with that described by Joel Reardon here > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/1df04806-96e0-4660-858b-6d890e7eb6b1n%40mozilla.org?utm_medium=email&utm_source=footer> > (see discussion beginning with “Another strange thing is that whois > information lists Wylie Swanson as the registrant for a number of domains > that closely mimic other encrypted email products [26]). > We’ve separately confirmed the domain registrations described above were once > registered as indicated by Joel. > > > Additional Observations > > Separately, we noted the following observations after taking a closer look at > Msgsafe.io and studying TrustCor’s certificate issuance. > > Msgsafe.io > TrustCor owns msgsafe.io <http://msgsafe.io/>, a privacy-focused webmail > platform that appears popular across ransomware attacks (examples [4 > <https://www.bleepingcomputer.com/news/security/leaked-lockbit-30-builder-used-by-bl00dy-ransomware-gang-in-attacks/#:~:text=%27filedecryptionsupport%40msgsafe.io%27>], > [5 <https://howtofix.guide/crypt-file-virus-decryptmsgsafe-io/>], and [6 > <https://malwaretips.com/blogs/remove-bannedlands-msgsafe-io-contact/>]). > > Bad actors’ use of TrustCor’s service offering should not be considered a > representation of the service, or TrustCor, itself. However, we are curious > to understand actions TrustCor has taken against the addresses represented in > the attacks described above, and others that may have been reported in the > past. While TrustCor’s responses to known instances of abuse are not directly > related to its position as a trusted CA, they could be interpreted as a > demonstration of TrustCor’s commitment to upholding security and privacy on > the web. > > Certificate Issuance > We studied TrustCor's TLS server certificate issuance and did not find signs > of mis-issuance or clear violations of the Baseline Requirements. > > We identified that ~35% of the dnsNames represented in the certificates > issued by TrustCor were publicly accessible at the time of evaluation, and > only 59% of those served TrustCor-issued Certificates. > > Closely studying issuance patterns, most TrustCor-issued certificates were > issued to the following domains: ddns.net <http://ddns.net/>, hopto.org > <http://hopto.org/>, sytes.net <http://sytes.net/>, zapto.org > <http://zapto.org/>, myddns.me <http://myddns.me/>, servebeer.com > <http://servebeer.com/>, myftp.org <http://myftp.org/>, and servehttp.com > <http://servehttp.com/>. > > We would have expected a substantially broader set of publicly accessible > domains, but this is not intended to express wrongdoing by TrustCor. > > > If there are any questions regarding any of the items above, we’d be happy to > address them. > > - Ryan > > > On Tue, Nov 8, 2022 at 1:58 PM Rachel McPherson <rac...@trustcor.ca > <mailto:rac...@trustcor.ca>> wrote: >> Hi Joel and Serge, >> >> Interesting that this is the first time you or anyone else in your research >> group has reached out to us, except if you count the Washington Post >> journalist who claims in his article that we did not respond, which is one >> of the many false claims made in the article since we responded very quickly >> to his contact. And before I begin, you should probably clarify if your >> views are representing The University of Calgary’s views, The University of >> California at Berkeley’s views, or your commercial endeavor AppCensus’s >> views, or your views representing any customer, agency, etc…? If in fact >> these views are completely independent and personal, that is also helpful to >> note. >> >> For any of the technical details about MsgSafe.io <http://msgsafe.io/>’s >> email software and service, that belongs in a different forum as it is not >> related to CA operations or CA public policy based on your description. I >> know you guys promote some kind of app security solution commercially, but I >> did note in my earlier response that our company and MsgSafe has never >> shipped an app that was not in BETA only and that the 5-year-old app beta >> was abandoned years ago and replaced with a mobile-first web experience that >> we think is really quite awesome on the phone browser itself without having >> to install any app software which is (as you guys well know) dangerous when >> it comes to navigating the 3rd party software that helps make apps easier to >> use or helps monetize them or whatever, but may also contain other stuff bad >> guys use for their own purposes. We abandoned mobile development years ago >> (as you can clearly tell) and instead of replacing it we just suggest users >> make use of their built-in browsers only to use the service which as you can >> see for yourself works amazingly well now based on React Native’s mobile >> capabilities. This is by far the safest way to use the email app from what >> I’ve been told by the team, but again in that other forum please share your >> suggestions because of course we want to make it even better. I encourage >> you to follow those up with the MsgSafe.io <http://msgsafe.io/> directly via >> their customer support channels and I know for a fact they will be thrilled >> if you can provide any positive suggestions for improving that product >> suite, and thank you in advance for that. I know they get a lot of >> suggestions, but everything helps when it comes to making products better >> and more secure, I think that’s one thing we all agree on. My suggestion is >> you don’t start the conversation with them talking about an abandoned app >> beta from many years ago (except maybe to say remove it), and instead focus >> on improving their production web application for mobile. >> >> Specific to your commentary on the certificate authority and policy >> pertinent to this forum, I appreciate that you recognize and stated multiple >> times throughout your post that you have found no evidence of TrustCor >> mis-issuing certificates or otherwise abusing our authority or violating >> established CA policies or root policies. We obviously agree. I’m going to >> comment on a few of your other points for the benefit of this forum, and >> then I suggest we take things off-line (sideline at least) and either meet >> in person or have phone calls or professionally approach our discourse some >> other way, without you guys using the media, your twitter forces or slinging >> more false claims, which isn’t good for anyone including the public that we >> both hope to serve. >> >> I’m not an attorney, but when a company registers itself as a corporate >> entity and lists its officers and addresses and mailing addresses and uses >> attorneys to do those things, often times the company initially gets >> registered to the attorney or there and then that information gets >> immediately obsoleted through amendments pointing to the real officers. I >> can tell you we don’t have any crossover between our officers and the >> officers of the other companies you mention, for certain. As for the >> ownership or beneficial shareholders of the company, the names you list are >> close, but wrong. We have had the same beneficial owners for 7 years, and >> while their names are "similar to" the names you mentioned, they are not >> identical and we certainly never had any ownership from companies registered >> in the USA. As for the cross-over between officers, I am as perturbed as you >> because what that website is showing (open corporates) and probably what the >> gov attorneys have in our records is absolutely not what exists in my files, >> so obviously it is my duty to reconcile this with the ownership and get it >> corrected and most importantly explained. Without having researched any of >> that, I will again refer to those other random USA companies that are not >> us, and that were created in other jurisdictions 7 years after we were >> incorporated, that sound similar to our ownership, and their potential for >> foul play against us in this way along with the insurance information >> attempt I mentioned before. It looks like the real companies were there >> before, but were modified and the attorneys and individuals were added to >> the record, whereas our records show slightly different names and without >> that individual. Again, I will reconcile and explain after I’ve done more >> research and compared these things on the complete timeline of events. >> >> Also, we are not in USA territory based on ownership, though as you pointed >> out we do host some equipment in the USA. I don’t think it’s common for >> companies to disclose where any of their critical hosting infrastructure is >> located, but yes we have infrastructure in the USA and in the Caribbean, and >> our key locations are properly documented in our CA audits and insurance >> filings. >> >> When I read your comments about the company names and the domain name, it >> seems like we already explained this in our initial reply to the extent my >> attorney is comfortable with me explaining publicly because we are concerned >> about follow-on civil lawsuits. Plainly stated, it looks like 7 or so years >> after we were founded, someone went and created companies with similar names >> (but instead of creating them where they belong and are already registered, >> they created them inside the USA). I don’t know for a fact why anyone would >> do this, we certainly did not do it. Our attorneys believe someone could >> have done this (and it agrees with our event timeline we’re creating as we >> investigate) for physical actions taken and may have used this with >> insurance companies to obtain additional nonpublic information about our >> company and our insurance infrastructure which is large and complicated just >> like every CA’s insurance has to be. When you pair that with someone also >> having a lookalike domain name, obviously that could be used for bad >> purposes (phishing, etc) against our clients or against us or against our >> vendors I guess, … that doesn’t look like a good combination. It looks quite >> nasty, actually. When we realized the domain name was out there, we took >> legal action and we had asserted international trademark claims and we were >> able to force the domain be sold to us and we have it and use it today. Who >> would register those companies or domain or do these things to us and why? >> That’s beyond me, but none of it sounds like good behavior to me or to our >> attorneys. If you guys have any actual evidence of better ideas as to how >> these could have been used, I’d like to share that with our attorneys. >> >> I think I’ve hit on all the big points I can talk about publicly, obviously >> I can’t comment on prior (whether deceased or not) employees, etc. >> >> Oh and on our own domain ownership or prior employee domain ownership, >> frankly that again has to do with that MsgSafe email product and not CA >> operations, but our customers and the company and prior and current >> employees etc all register domains through it by the hundreds or thousand(s) >> there are at some level of provisioning or not, and we really can’t be >> responsible for what they all register. Certainly if any violate any >> guidelines we try to handle that on an individual case basis, but hopefully >> abuse is kept to a minimum and we have a lot of protections built-in like >> checking against Alexa top sites and other things CAs do operationally as >> part of the business. Some but not all of these protections are extended to >> the MsgSafe email product but that can be blurry because people register >> some really weird domains quite naturally and without any malice that >> contain weird words or substrings or whatever… >> >> As I said happy we are to take this offline with our CA operational partners >> and fellow root program stakeholders and administrators, etc. >> >> Thank you everyone, >> >> Rachel >> >> Please note: this message is not in direct reply to Kathleen’s message that >> just came in, we have not yet had time to absorb her post and will reply to >> Kathleen’s message on all mentioned points within the timeframe allotted. >> However, we did not feel the need to delay our response to Joel and Serge. >> >>> On Nov 8, 2022, at 11:38 AM, Serge Egelman <egel...@cs.berkeley.edu >>> <mailto:egel...@cs.berkeley.edu>> wrote: >>> >>> I want to follow this up with some additional details that I've found: >>> >>> We initially came across this CA after discovering the malware SDK that >>> Joel described. We went through some of our app analysis data to find all >>> the apps impacted and reported those to Google. In every case, save one, >>> that SDK was heavily obfuscated (going so far as to encrypt strings, which >>> were then decrypted dynamically at runtime). We found a pre-release beta of >>> the MsgSafe app that contained the only unobfuscated version of the SDK >>> that we had seen in the wild. For example, here's a screenshot made after >>> decompiling that app using apktool: >>> <Screenshot 2022-11-08 at 8.26.43 AM.png> >>> >>> You can see full debug symbols, which don't exist in any other version of >>> the app that we've found. >>> >>> According to their Twitter feed, they released a beta of their Android app >>> in late 2017: >>> <Screenshot 2022-11-08 at 8.18.04 AM.png> >>> https://twitter.com/msgsafeio/status/951217954158530560 >>> https://twitter.com/msgsafeio/status/933450622271217665 >>> >>> While that app is no longer in the Play Store, there are third-party app >>> archives that have made it publicly available. For example: >>> https://apkpure.com/msgsafe-io-unreleased/io.msgsafe.android/download?from=versions >>> >>> Like most Android apps, it's signed, so someone else can probably >>> independently verify its provenance. >>> >>> So the question is, why did MsgSafe appear to bundle an unobfuscated >>> version of this SDK in their app? How was it obtained, if as Rachel says, >>> they have nothing to do with the company that is spreading it? According to >>> her email, they don't have a public app; someone should probably tell that >>> to their social media person... >>> >>> >>> serge >>> >>> >>> >>> On Tuesday, November 8, 2022 at 7:52:25 AM UTC-8 joel.r...@ucalgary.ca >>> <http://ucalgary.ca/> wrote: >>>> Hello all: >>>> >>>> I'm Joel Reardon, a professor at the University of Calgary, who researches >>>> privacy in the mobile space. Earlier this year, collaborators and I >>>> uncovered >>>> and disclosed a spyware SDK embedded in apps that were invasively tracking >>>> users >>>> [1]. The SDK was banned from the Play Store and apps that included this >>>> SDK were >>>> told to remove it or they would be removed from the Play Store. >>>> >>>> The SDK was from a Panamanian company [2] called Measurement Systems [3]. >>>> Their >>>> website's WHOIS information listed Vostrom Holdings [4] as their owner when >>>> I had started the investigation; it is now anonymized for privacy, but >>>> historical >>>> information is available [5]. >>>> >>>> Along with investigative journalists at the Wall Street Journal, we >>>> discovered >>>> that Vostrom Holdings is doing business as Packet Forensics [6], a >>>> company that sells lawful-intercept products [7]. The Measurement Systems >>>> company was also registered in Virginia [8] by "Raymond Alan Saulino", >>>> which was >>>> then made inactive when Google took action against the SDK [9]. "Raymond A >>>> Saulino" is also an officer for Packet Forensics International LLC [10], >>>> and >>>> despite the middle name not being an exact match, they both list the same >>>> residential address [11, 12]. >>>> >>>> So now let's get to why I'm talking about this here on this forum. After >>>> we found >>>> that the SDK domainss were registered by Vostrom, we looked to see what >>>> else was also >>>> registered [13]. One of the domains stood out: trustcor.co >>>> <http://trustcor.co/>, which redirected at >>>> the time to the TrustCor CA's website. The NS records continue to point to >>>> nsX.msgsafe.io <http://nsx.msgsafe.io/> [14], the same as trustcor.com >>>> <http://trustcor.com/> itself [15]. Msgsafe is a TrustCor >>>> encrypted email product [16]. >>>> >>>> Like Measurement Systems, Trustcor is also registered in Panama [17]. They >>>> were >>>> registered a month apart and they share an identical set of corporate >>>> officers >>>> (cf. [1]). It is my understanding that these officers only are involved in >>>> three >>>> companies, so it does not appear that they register, e.g., many companies >>>> in >>>> Panama. One of these officers is Frigate Bay Holding LLC [18]. Shortly >>>> after >>>> the WSJ article was printed, a "Raymond Saulino" filed paperwork for >>>> Frigate Bay >>>> Holdings LLC listed as its manager [19]. Raymond Saulino has also spoken >>>> to press >>>> publicly on behalf of Packet Forensics in the context of a Wired article >>>> about >>>> subverting SSL [20]. >>>> >>>> Trustcor also talks about their "geo-jurisdiction advantage" on an entire >>>> page >>>> [21] where they state that "TrustCor is a Panamanian registered company, >>>> with >>>> technical operations based in Curaçao---one of the most secure, privacy >>>> oriented >>>> jurisdictions in the world." Despite that, they have job openings for PKI >>>> Engineer and Systems Engineering in Phoenix, AZ [22, 23], the latter >>>> stating that >>>> the applicant "MUST be located near the Phoenix, AZ area - job is remote >>>> with >>>> occasional trips to data center facilities". Their own audit reports state >>>> that >>>> they are Canadian, with their data centres in Phoenix, AZ [24]. I am not >>>> particularly troubled by where they have their technical operations, but I >>>> think >>>> that it is strange to omit that the data centres are in Arizona on the >>>> lengthy >>>> descriptions of the "geo-jurisdiction advantage". Certificate authorities >>>> are >>>> about trust. >>>> >>>> I have also tested the Msgsafe encrypted email product in the browser, >>>> while >>>> saving the resulting traffic using Firefox and Chrome's "save to HAR" file >>>> option. >>>> I am not convinced there is E2E encryption or that Msgsafe cannot read >>>> users' >>>> emails. I see that email contents and attachments are sent plaintext >>>> (over TLS) to api.msgsafe.io <http://api.msgsafe.io/>, even when sending >>>> to other Msgsafe users or when >>>> using PGP or SMIME to send to non-Msgsafe users. The SMIME cert is sent >>>> inbound >>>> from the server, and there is no outbound traffic that embodies the public >>>> key >>>> to be signed. The password is sent plaintext to the server (over TLS) and >>>> thus >>>> any key derived from that password would also be known by the server. >>>> Hanlon's >>>> razor tells me I should not attribute these errors to malice; it could >>>> just be a >>>> developmental failure [25]. Nevertheless, I think it is reasonable >>>> expectation >>>> that a root certificate authority can get the crypto right, and so I'm >>>> concern >>>> regardless of the reason why. >>>> >>>> Another strange thing is that whois information lists Wylie Swanson as the >>>> registrant for a number of domains that closely mimic other encrypted email >>>> products [26]. This includes hushemail.net <http://hushemail.net/>, >>>> protonmails.com <http://protonmails.com/>, and tutanoto.com >>>> <http://tutanoto.com/>, >>>> which shadow competing services, and which redirect users who visit them to >>>> msgsafe.io <http://msgsafe.io/>. Wylie Swanson is the co-founder of >>>> Trustcor [27]. In my opinion, >>>> it looks like typo squatting and I would not expect that a root certificate >>>> authority to be engaged in this kind of behaviour. >>>> >>>> To be clear, I have found no evidence of Trustcor issuing a bad >>>> certificate or >>>> otherwise abusing the authority they have in code signing, SMIME, and >>>> domain >>>> validation. I have only checked the public certificate transparency logs >>>> because >>>> I am unaware of comparable public auditing for code signing and SMIME. >>>> Perhaps >>>> Vostrom registered a similar-sounding domain for Trustcor and redirected it >>>> as an act of service. Perhaps the identical ownership of Trustcor and >>>> Measurement >>>> Systems is a coincidence. Perhaps the Raymond Saulino of Frigate Bay >>>> holdings is >>>> a different Raymond Saulino than the one representing Packet Forensics. >>>> >>>> I'm not familiar with the full policy side of how CA membership works, so I >>>> don't know if there is an expectation of candor regarding a CA's foreign >>>> ownership or connection to lawful intercept companies. Perhaps what I'm >>>> reporting is already known and not a concern, or perhaps there is a totally >>>> reasonable explanation for all these coincidences. Nevertheless, I feel I >>>> should >>>> disclose my findings just in case it ends up being useful, because I think >>>> that >>>> it is reasonable for a root certificate authority to assuage my concerns. >>>> >>>> A final coincidence: one of Msgsafe's email domains is decoymail.com >>>> <http://decoymail.com/>, which >>>> Msgsafe users can request and which redirects to msgsafe.io >>>> <http://msgsafe.io/> [28]. In 2014 it was >>>> registered to VOSTROM Holdings, Inc., while in 2015 it was registered to >>>> TRUSTCOR >>>> SYSTEMS S. DE R.L. [29]. DecoyMail was a company created by Rodney Joffe >>>> [30], >>>> who is the person who also filed the original registration of Packet >>>> Forensics >>>> [31] and was still an authorized agent for Packet Forensics in a 2019 >>>> filing >>>> [32] and a Manager for Packet Forensics in a 2021 filing [33]. The email >>>> rjo...@centergate.com <> is linked to the domains rodneyjoffe.com >>>> <http://rodneyjoffe.com/>, >>>> packetforensics.com <http://packetforensics.com/>, and decoymail.net >>>> <http://decoymail.net/> [34]. Decoymail.net <http://decoymail.net/> >>>> currently redirects >>>> to msgsafe.io <http://msgsafe.io/>. >>>> >>>> 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. Were Trustcor simply an email service that >>>> misrepresented >>>> their claims of E2E encryption and had some connections to lawful intercept >>>> defense contractors, I would not raise a concern in this venue. But >>>> because it is >>>> a root certificate authority on billions of devices---including mine---I >>>> feel it >>>> is reasonable to have an explanation. >>>> >>>> [1] https://archive.ph/AuNOy (archive of WSJ article) >>>> [2] https://opencorporates.com/companies/pa/2337L >>>> [3] https://measurementsys.com/ >>>> [4] https://vostrom.com/about.opp >>>> [5] https://www.whoxy.com/measurementsys.com >>>> [6] >>>> https://cis.scc.virginia.gov/CommonHelper/DocumentStorageLocalFileget?DocumentId=1542553&sourceType=1 >>>> [7] https://www.packetforensics.com/products.safe >>>> [8] >>>> https://cis.scc.virginia.gov/CommonHelper/DocumentStorageLocalFileget?DocumentId=3476851&sourceType=1 >>>> [9] >>>> https://cis.scc.virginia.gov/CommonHelper/DocumentStorageLocalFileget?DocumentId=12188858&sourceType=1 >>>> [10] https://opencorporates.com/companies/us_nv/E0518742015-4 >>>> [11] https://opencorporates.com/officers/429641126 >>>> [12] https://opencorporates.com/officers/168691865 >>>> [13] https://www.whoxy.com/company/20189182 >>>> [14] https://www.whoxy.com/trustcor.co >>>> [15] https://www.whoxy.com/trustcor.com >>>> [16] https://trustcor.com/news/12012016.php >>>> [17] https://opencorporates.com/companies/pa/2326L >>>> [18] https://opencorporates.com/companies/us_wy/2020-000946985 >>>> [19] >>>> https://wyobiz.wyo.gov/Business/FilingDetails.aspx?eFNum=230084239221021253238165142128171020141144245186 >>>> (click on history, then address update pdf) >>>> [20] https://www.wired.com/2010/03/packet-forensics/ >>>> [21] https://trustcor.com/curacao >>>> [22] >>>> https://careers.jobscore.com/careers/trustcor/jobs/pki-security-engineer-cGlJUDydTp67nWF6LOxNC0?ref=rss&sid=68 >>>> [23] >>>> https://careers.jobscore.com/careers/trustcor/jobs/systems-engineer-aNkuyi0pKr6R6NaKlhlxBf?ref=rss&sid=68 >>>> [24] >>>> https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=c4f0e7c6-b310-4f5c-9907-8ecfad68366e >>>> [25] https://en.wikipedia.org/wiki/Hanlon%27s_razor >>>> [26] https://www.whoxy.com/email/28298508 >>>> [27] https://trustcor.com/leadership >>>> [28] https://decoymail.com <https://decoymail.com/> >>>> [29] https://securitytrails.com/domain/decoymail.com/history/a (need to >>>> create account) >>>> [30] >>>> https://ecorp.azcc.gov/CommonHelper/GetFilingDocuments?barcode=00396622 >>>> [31] >>>> https://ecorp.azcc.gov/CommonHelper/GetFilingDocuments?barcode=02780271 >>>> [32] >>>> https://ecorp.azcc.gov/CommonHelper/GetFilingDocuments?barcode=19121111449561 >>>> [33] >>>> https://bizfileonline.sos.ca.gov/api/report/GetImageByNum/190229140180179177132144027172122051178173016008 >>>> [34] https://www.whoxy.com/email/23160817 >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org>" >>> group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to dev-security-policy+unsubscr...@mozilla.org >>> <mailto:dev-security-policy+unsubscr...@mozilla.org>. >>> To view this discussion on the web visit >>> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/f5ab3236-2a16-42e6-b33d-6e142c1b49cen%40mozilla.org >>> >>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/f5ab3236-2a16-42e6-b33d-6e142c1b49cen%40mozilla.org?utm_medium=email&utm_source=footer>. >>> <Screenshot 2022-11-08 at 8.18.04 AM.png><Screenshot 2022-11-08 at 8.26.43 >>> AM.png> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org>" >> group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to dev-security-policy+unsubscr...@mozilla.org >> <mailto:dev-security-policy+unsubscr...@mozilla.org>. >> To view this discussion on the web visit >> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/63F407D0-3AD3-40CB-912E-3E4C2ABD2CCC%40trustcor.ca >> >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/63F407D0-3AD3-40CB-912E-3E4C2ABD2CCC%40trustcor.ca?utm_medium=email&utm_source=footer>. > > > -- > You received this message because you are subscribed to the Google Groups > "dev-security-policy@mozilla.org" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dev-security-policy+unsubscr...@mozilla.org > <mailto:dev-security-policy+unsubscr...@mozilla.org>. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADEW5O-QOZuaEpZJV8hwxb_CZb17z%2BB1SARsgbn2wPXqhdVoEg%40mail.gmail.com > > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADEW5O-QOZuaEpZJV8hwxb_CZb17z%2BB1SARsgbn2wPXqhdVoEg%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/4BDDA4BA-ACDA-4278-A753-85DD7AB0A607%40apple.com.
smime.p7s
Description: S/MIME cryptographic signature
