On Fri, Nov 18, 2022 at 2:14 PM Rachel McPherson <[email protected]> wrote:
> Kathleen, Ryan, Clint and the rest of the community: > > 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). I appreciate working > with many of you for many years and your positive messages were very > meaningful and heartfelt. Given the publicity of this forum, I will do my > best to respect individuals by not constantly using their names or calling > out other root program member organizations as examples, even when it would > be helpful to do so. Instead I will ask you to consider that aspect in my > response. Also, I will use "our company" when speaking of TrustCor (the CA > operator) and MsgSafe (the email service). I will use "the researchers" > when speaking about Serge Edelman, Joel Reardon, their commercial > enterprise AppCensus, or the universities for which they work (University > of California, Berkeley and the University of Calgary, respectively). > > It is important readers understand we have never been accused of, and > there is no evidence to suggest that TrustCor violated conduct, policy, or > procedure, or wrongfully issued trusted certificates, or worked with others > to do so. We have not done any of those things. It’s also important to > understand TrustCor operates a certificate authority (TrustCor CA) which > provides CA services protected and insulated by an exclusion agreement, and > TrustCor operates a privacy-enhancing communications service (MsgSafe.io) > as two distinct business units. > My I am not accused of missiuance t-shirt is raising questions answered by my t-shirt. > I will do my best to succinctly respond to the questions and concerns from > the representatives from the root programs representatives first, and then > for the readers wanting additional detail, I will provide more context in > the sections below the most pertinent information of my response. I have > also attached a memo from Wylie who wanted to be heard as part of this > process. For those of you who want to cover (journalism) the topic, thank > you in advance for considering the whole message and attachments before you > write anything or before you call us, please. > > ——————————— > > > *In Response to Kathleen’s (Mozilla) concerns, providing further > clarification as requested:* > > *In Response to "How was an unobfuscated version of the Measurement > Systems SDK incorporated into MsgSafe?":* > > Our company never published a production or supported version of the > MsgSafe mobile app containing the Measurement Systems SDK. Relative to the > tiny population of Beta product-testers (which were largely our own > employees) who chose to test a Beta version of the app containing that SDK, > I will add that during the development stages of MsgSafe’s BETA mobile app, > our developers sought out the help from 3rd party software services to > obtain better app analytics. We are aware that they evaluated other SDKs > and tools like Firebase, Bugsnag, etc. but they claimed to not help much in > troubleshooting and improving the app functionality across all device > manufacturers and OS versions. There was a time during this process where > they incorporated additional software developers to help with the issues we > were facing. Whether or not the SDK was added for a developer’s own > financial gain or otherwise is beyond us and we don’t care to speculate. > Again, the MsgSafe BETA mobile app was never released in a production > supported version and has been abandoned for years, and we can confirm the > mobile-first web UI, which is the only supported mobile interface in-use > today and for the last few years, which does not contain any SDK from > anyone. > > > As far as how the MsgSafe mobile app obtained an “unobfuscated version” of > the SDK? It is not our place to speculate, but it only makes sense that any > company would provide updates to their software over time. The third-party > app archive website containing MsgSafe’s APK, as referenced in the > researcher’s post, is over 3 years old. It should come as no surprise that > the software found there doesn’t match up exactly to the software found in > apps they reported about in April 2022. Our developers probably didn’t even > notice subtle changes like this because it’s not our practice to reverse > engineer other company’s software and violate license agreements. > > > > *In Response to "**Explanation of the ownership, governance, and > relationship between Trustor, Measurement Systems and Packet Forensics > International, especially focusing on how the documented actions by other > Vostrom Holdings organizations such as Measurement Systems impact TrustCor > and its operations.* > > *To what extent does TrustCor today maintain a business relationship or > share ownership/ corporate officers with Measurement Systems or Packet > Forensics?":* > > TrustCor does not have or maintain any business relationship or share any > officers or ownership with Measurement Systems or Packet Forensics, or any > other defense company. The documented actions and opinions do not > impact TrustCor's CA operations in any way. Additionally, any > shareholders have no control over our CA operations (as enforced by our > exclusion agreement), and any misbehaviour of organizations or individuals > external to us are a result of their decisions and do not affect our > operations. > > > *In Response to "If Trustcore today does not maintain a business > relationship or share ownership/corporate officers, has it done so in the > past? If so, when? When was the relationship disolved?”:* > > 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 do not understand how "having a group of investors in common" is the same as "there is not and has never been shared ownership with any defense company or USA company". Could you clarify the corporate structure and ownership of all major investors as well as shared officers among all entities? > *In Response to "What in general explains the shared corporate officers > across the companies?”:* > > The initial investors/founders of both holding companies were known to > each other and decided to diversify their investments across multiple > companies and in multiple territories, which is apparently a common > funding practice. They are strictly passive investors, with the exception > of Ian Abramowitz. > > This answer does not make sense to me. If the investors and founders were engaged in a diversification transaction, and that lead to shared corporate officers, that would not be "passive" as commonly understood, e.g. as per SEC guidance in https://www.sec.gov/corpfin/divisionscorpfinguidancereg13d-interphtm#103.11. Would it be possible to share a comprehensive list of dramatis personae? > *In Response to "Do you have separate corporate registration documentation > demonstrating that the TrustCor CA is a different organization than the > Trustcor entity that shares corporate officers with Measurements Systems. > If so, please provide it.”:* > > (from above) 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. Once it > completes we will be pleased to share the public records, but we cannot > control how long it takes various attorneys to reflect changes upon death, > etc. Obviously Ian’s name is on many records already publicized and > searching for his name allows anyone to see his memorial website from June > 2022 (but he had been in treatment for some time) and other public records > of this type. Since its inception in 2013, TrustCor’s CA business unit has > been completely insulated and protected from any shareholders through its > exclusion agreement, which separates equity ownership from access-to or > control-over the CA business unit. > > Is this agreement together with articles of incorporation something you can share? It appears from your answer that these were not separated entities until recently: could you confirm that each step in the change of control was properly reflected in the CCADB? > *In Response to "State the number of SMIME certificates whose private keys > were stored in versions of the MsgSafe app which included the identified > malware. State TrustCor CA’s plan for those certificates; e.g. timeline > for revoking them.”:* > > No private keys were ever stored on the MsgSafe mobile application, > including in the unreleased BETA version referenced by the researchers. > Therefore, we do not see any reason to revoke any of the > S/MIME certificates issued within the timeframe that the MsgSafe Beta > mobile app was in circulation. In addition, all of TrustCor’s S/MIME > certificates are issued with a validity period equal to 365 days or less. > Any S/MIME certificates issued to MsgSafe users during the timeframe of the > BETA app would all be expired and invalid a long time ago. > > > *In Response to "Self-assessment of risk versus benefit of the TrustCor > CA’s root certificates being included in Mozilla’s root store with the > websites (TLS) and email (S/MIME) trust bits enabled. Please > see https://wiki.mozilla.org/CA/Quantifying_Value > <https://wiki.mozilla.org/CA/Quantifying_Value> for the information to be > provided.”:* > > We have provided the CA-Quantifying Value Statement as a separate > document, attached. > > We can discuss this document in detail: I found it highly superficial and believe that essential elements of the questions weren't answered. > > *In Response to "Statement of Auditor’s Qualifications, as explained > here: > https://wiki.mozilla.org/CA/Audit_Statements#Providing_Auditor_Qualifications”: > <https://wiki.mozilla.org/CA/Audit_Statements#Providing_Auditor_Qualifications”:>* > > TrustCor’s WebTrust audit is performed by Princeton Audit Group, Inc. > (“PAG”), with the accreditation found here: > <https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/licensed-webtrust-practitioners-international> > https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/licensed-webtrust-practitioners-international > > PAG’s lead auditor is Vijay Khosla and PAG’s team of auditors carry CISA > and CISM certifications and relevant in-house training. Average years of > experience, in trust services or similar information systems, for the audit > team includes 34 years in IT Audit Audits, 10 years in SOC 1,2,3 reporting, > 5 years in SOX, 10 years in WebTrust Audits. Qualifications include: over > 10 years in: IT and Infrastructure Audit, SDLC and Risk Assessment; Data > Center Audits; Encryption training; Cost Accounting Experience; Physical > Security; Network Security; and Cloud Computing. > Credentials include: CPA, CISA, CISM, AICPA, CPA Canada PAG audit team > members are bound by law to comply with standards applicable to their > respective qualifications and also as required for e.g. AICPA, CISA, CISM > and CPA Canada. As of TrustCor’s 2021 audit period, PAG does not rely on > any third-party specialists or affiliate audit firms. > > PAG seems to have only audited TrustCor among CAs. I alas couldn't find a history of the audits: has TrustCor always used PAG? Does TrustCor have a plan to rotate auditors as is consistent with financial best practices? > > > *In Response to the concerns and questions from the researcher’s post as > specifically referenced by Kathleen are included in-line below:* > *In Response to "There is substantial evidence that Measurement Systems > and TrustCor are closely related: Both had their domains registered by > Vostrom Holdings. (as illustrated in this post by AppCensus on the basis > of whois lookups)”:* > > 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. In the early days of the long transition and upgrading > (porting to a different programming language) of the software from the > DecoyMail service to the MsgSafe.io service (which took years), these > domains were registered while the software was still pointed to the same > registrar account of the previous owner which owned many other domains > including others unrelated DecoyMail customer domains and also domains of > the registrar account owner. Even still, it was not even a > corporate/wholesale account, it was a personal account with a variety of > domains held by one of the original DecoyMail shareholders. The platform > was not officially relaunched for several years when it was announced as > MsgSafe.io as shown here: https://trustcor.com/news/12012016.php. Even > after relaunching it, several more years passed before all domains were > migrated to the production registrar, DNSimple, and we are not even certain > they were all migrated — some DecoyMail users did not transition their > accounts fully and some lookalike domains were not identified because they > were lookalikes or homoglyphs and not critical to the company branding > or functionality. > > Are you asserting that the Measurement Systems and TrustCor domains were both registered via Decoy Mail? > > *In Response to "They have identical corporate officers: Measurement > Systems, Trustcor Systems”:* > > > This statement is inaccurate because the funding/holding companies in > question were already dissolved in 2021. We have explained our > restructuring (above) and cannot speak with regard to the other company > because we do not know them. It is worth noting that the media's coverage > does not indicate who is the beneficial owner of Measurement Systems. > > 2021 was last year. I can recall events from last year with some degree of reliability. Certainly it's possible to explain who the owners were of the company last year and the transactions that changed it. > The reporting and public records merely indicate that an individual > affiliated with a defense company (investor or former employee) may also be > an investor in one or both of the funds/holding companies and therefore > potentially was at some time an investor in our company through an > investment in another company. > > Most companies are capable of presenting an accurate list of their stock holders, and reaching through their holding companies if on good terms. Is it not possible to fully explain the ownership of these related companies? > The researchers' conclusions that the journalists further expound are > confusing the facts. For example, if it holds that any "investor" in one > company (making them an "affiliate" of that company) is also affiliated as > an "investor" in another company, links the two companies together as > affiliates, and then even when one of those two companies further invests > in a third company (one part removed), basically most businesses and even > CAs come into question because of the suggested transitive property. Also > conflated by the researchers and media is the point about American > corporations bearing similar (not exactly the same) names to those of the > funds/holding companies in question. We are not now and never have been > owned by any American company with any names similar to those pointed out > by the researchers. We have no idea what those companies are or what are > their purpose, but they are not affiliated with our company or anyone known > to us. Our business was formed in Panama over 9 years ago and any > paperwork filed in the last few years, pointing to an American > or similar-named company was not executed by us or affiliated with us in > any way. > > > *In Response to "TrustCor operates the mail encryption product MsgSafe and > a beta version of MsgSafe contained the only known unobfuscated version of > the spyware SDK. (Beta APK, inspected by Joel and signed by Google)”:* > > Our company never published a production or supported version of the > MsgSafe mobile app containing the Measurement Systems SDK. Relative to the > tiny population of Beta product-testers (which were largely our own > employees) who chose to test a Beta version of the app containing that SDK, > I will add that during the development stages of MsgSafe’s BETA mobile app, > our developers sought out the help from 3rd party software services to > obtain better app analytics. We are aware that they evaluated other SDKs > and tools like Firebase, Bugsnag, etc. but they claimed to not help much in > troubleshooting and improving the app functionality across all device > manufacturers and OS versions. There was a time during this process where > they incorporated additional software developers to help with the issues we > were facing. Whether or not the SDK was added for a developer’s own > financial gain or otherwise is beyond us and we don’t care to speculate. > Again, the MsgSafe BETA mobile app was never released in a production > supported version and has been abandoned for years, and we can confirm the > mobile-first web UI, which is the only supported mobile interface in-use > today and for the last few years, which does not contain any SDK from > anyone. > > This seems to indicate that * TrustCor operated MsgSafe * TrustCor did not apply the same standards to MsgSafe development as it would to its core CA services, or did. In either way the conclusion would be that TrustCor is unable to exert effective control over the development process or is blithe to reputational risks from associated business activity. > As far as how the MsgSafe mobile app obtained an “unobfuscated version” of > the SDK? It is not our place to speculate, but it only makes sense that any > company would provide updates to their software over time. The third-party > app archive website containing MsgSafe’s APK, as referenced in the > researcher’s post, is over 3 years old. It should come as no surprise that > the software found there doesn’t match up exactly to the software found in > apps they reported about in April 2022. Our developers probably didn’t even > notice subtle changes like this because it’s not our practice to reverse > engineer other company’s software and violate license agreements. > > > *In Response to "The MsgSafe product relies in part on SMIME certificates > issued by TrustCor (MsgSafe Website)”:* > > MsgSafe.io is both a product and business, operated separately and > independently from TrustCor CA, albeit owned by TrustCor. MsgSafe.io > integrates > with TrustCor’s S/MIME certificate API for issuance of S/MIME certificates, > just like any other CA customer of TrustCor would do. In addition, > MsgSafe.io also allows customers to bring their own S/MIME certificates > (so not all of MsgSafe user’s certificates are generated by TrustCor CA). > > > > ——————————— > > *In Response to Ryan’s (Google) concerns, providing further clarification > as requested:* > > *In Response to "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. * > > It is not within our company’s purview to choose which auditors are > qualified or accredited to perform the required WebTrust audits. We merely > follow the root program and CA/B guidelines and select from the published > list. Our founders originally called and spoke with most of the auditors on > the published list at the time and have used the same one ever since > because as I’m sure you’ve seen with other program members, once you have > an auditor it is easier and more cost effective to continue using the same > one year after year. The list is published here and as you can see our > auditor remains an accredited auditor (PAG was on the list since before our > company was founded and still is today). If there is a compelling reason > you or any root program manager has to select another auditor, we are > certainly open to changing if that is required, and it appears as though > the list is now much longer almost ten years after we first had to choose. > > Using the same auditor for 10 years, no matter how honest, introduces risks of excessive chumminess and normalization of deviance. I would consider it a reasonable change to CA/B guidelines to require rotation just as SOX does for audits of public companies. However, it is surprising that TrustCor management did not consider this in selection of auditors. > > > https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/licensed-webtrust-practitioners-international > > > > > > *TrustCor’s most recent audit statements ([Standard] and [BR - TLS]) > describe CA operations in Toronto, Ontario, Canada. PAG is listed as a > licensed practitioner only in the USA.TrustCor’s CPS indicates the data > centers are located in Phoenix. Though the management assertion references > Phoenix, PAG’s attestation does not. * > > As you stated, it was included in the management’s assertion and it > appears to be a clerical error that PAG’s attestation did not additionally > include the location of TrustCor’s data centers specifically, but we did > confirm with our auditor that this will be included in PAG's 2022 > attestation. In addition, under *5.1.1 Site Location and Construction*, of > TrustCor’s CPS, we also state that TrustCor CA’s data centers are located > in Phoenix, Arizona, USA, which are visited and audited annually. > > > > *Beyond [1], [2], and [3], we found little public information specific to > audits performed by PAG.* > > > It is not within our company’s purview to choose which auditors are > qualified or accredited to perform the required WebTrust audits. We merely > follow the root program and CA/B guidelines and select from the published > list. Our founders originally called and spoke with most of the auditors on > the published list at the time and have used the same one ever since > because as I’m sure you’ve seen with other program members, once you have > an auditor it is easier and more cost effective to continue using the same > one year after year. The list is published here and as you can see our > auditor remains an accredited auditor (PAG was on the list since before our > company was founded and still is today). If there is a compelling reason > you or any root program manager has to select another auditor, we are > certainly open to changing if that is required, and it appears as though > the list is now much longer almost ten years after we first had to choose. > > > > https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/licensed-webtrust-practitioners-international > > > *In Response to "Coincidence #2 WIPO Complaint”:* > > *This page 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 <http://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 (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.* > > The bfgoodrichpromotions.net complaint was not related to TrustCor CA’s > products or services but to MsgSafe.io’s privacy-focused email service. > Unfortunately, free or low-cost email service providers are often abused by > phishing, ransomware, and other abuse because they lend to privacy and > anonymity and how easily bad actors can acquire them. For instance, > bfgoodrichpromotions.net was registered by user who signed up for > MsgSafe.io's service with, and had their email forwarding to, their Gmail > account. In 2018, MsgSafe.io’s support staff indeed failed to handle this > event timely due to being overwhelmed by the high volume of abuse happening > at that time. As a result, MsgSafe.io implemented several abuse-reducing > solutions, dramatically decreasing the success of bad actors on the > platform and have since added support team members to respond within a > timely manner to all support tickets. > > To quote Ryan, "TrustCor’s service offering should not be considered a > representation of the service, or TrustCor, itself." > > Would you care to address the rest of the sentence of Ryan? > ——————————— > > *In Response to Ryan’s (Google) Additional Observations:* > > *MsgSafe.io <http://MsgSafe.io> * > *TrustCor owns msgsafe.io <http://msgsafe.io>, a privacy-focused webmail > platform that appears popular across ransomware attacks (examples [4], [5], > and [6]).* > > > *In Response to "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.”:* > > There is a niche out there for privacy-focused people who want private and > anonymous email services. This is why services such as [name suppressed for > politeness], MsgSafe.io and others are always in demand. Unfortunately, > these privacy-focused services, and frankly all free or low-cost email > service providers, are often used by ransomware developers because of how > they lend to privacy and anonymity, and how easily they can be obtained. > (examples of gmail being the most popular across ransomware attacks [1], > [2]). > > With that being said, we take spam/phishing very seriously and MsgSafe has > a zero tolerance policy, as clearly stated in its Terms and Conditions [3], > when we are aware of the services being used for malicious intentions. In > the examples of the email addresses used in the ransomware attacks > references by Ryan, none of these were brought to our attention through our > standard support/abuse ticketing system, and if they had we would have shut > down the accounts immediately. Since becoming aware of these instances, we > can confirm that all 3 of these accounts have been terminated as of > 2022-11-15 for being in violation of MsgSafe’s Terms and Conditions. > > Another "leader move" in innovation for us worth noting along these lines > is we have implemented a completely-automated account closure system for > the most heinous abuses where we believe a human-in-the-loop is not > necessary, such as spam (also a policy violation). You cannot effectively > send high volume phishing or spam through MsgSafe using a combination of > automated account creation and/or high volume message-sending because of > built-in rate limiting, however we took an extra step to check constantly > for receive-rate abuses when spammers send mail through another high volume > spam sending system such as Gmail, and use a MsgSafe.io email as their > reply-to address or in their return-path, and when that rate-limit is > reached (indicating they did not spam through us, but still violated our > policy since a MsgSafe email address was used as an aspect of sending spam > through someone else), our automated system closes their account for policy > violation and automatically begins returning a helpful and informative > error message next time someone sends to their MsgSafe.io account, > letting everyone involved (victims, account holders or friends) their > account was closed due to abuse. > > 1. > https://www.bleepingcomputer.com/news/security/gmail-accounts-are-used-in-91-percent-of-all-baiting-email-attacks/ > 2. > https://www.computerworld.com/article/2517252/gmail-spam-uses-fake-addresses-to-spread-malware.html > 3. https://www.msgsafe.io/terms > > > > *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.* > > *In Response to "Certificate Issuance" points:* > > TrustCor is not aware of and works diligently to ensure there are no > mis-issuances or violations of the Baseline requirements. A large number of > the “dnsNames” represented are inaccessible because at that moment they are > not currently online (potentially dynamic dns working correctly), or were > accounts, or were proactively shutdown for any number of reasons. Given > this the 59% number may be accurate, but the 35% number is not necessarily > indicative of anything. > > We have innovated and lead the market in the adoption of TLS server > certificate issuance for one of the longest-running and most respected > dynamic DNS services worldwide and the positive impact this move has made > cannot be overstated. Dynamic DNS services are a critical aspect of > home-based IoT and "private cloud" solutions which have a dramatic and > important positive impact on personal privacy and security. Instead of > sending all your data to the cloud, dynamic DNS services allow users to > self-host their video cameras, data storage and IoT home automation > solutions in their home or small business, to enhance their privacy and > security. Until our partnerships in this area, obtaining server > certificates that operate properly with these private home systems relying > upon dynamic DNS was elusive, complex to implement, and therefore the > market was completely underserved. > > ——————————— > > *In Response to Clint’s (Apple) concerns, providing further clarification > as requested:* > > *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/ > <http://www.trustcorsystems.com/> (which redirects to https://trustcor.com/ > <https://trustcor.com/>), there is little mention, and nothing > predominantly represented, of products or services aside from TLS and > S/MIME certificate issuance.* > *In Response to "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?”:* > > > TrustCor is the parent company of TrustCor CA and MsgSafe.io. Certificate > issuance is core to the business of TrustCor. MsgSafe.io is a privacy > protection service. In relation to the certificate services that TrustCor > provides MsgSafe.io, MsgSafe.io acts like a customer of TrustCor, > leveraging TrustCor’s API to request S/MIME certificates for their > customers in support of MsgSafe’s email services. TrustCor, and the > associated website, predominantly promotes TrustCor’s CA business and > efforts, while the MsgSafe.io business separately markets and promotes > itself. MsgSafe.io is an example of privacy protection services. > > > *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/ > <https://www.washingtonpost.com/technology/2022/11/08/trustcor-internet-addresses-government-connections/>).* > *In Response to: "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.”:* > > TrustCor’s Ontario Headquarters address was previously located at 7270 > Woodbine Avenue, Suite 308 Markham ON L3R 4B9 Canada. When Ian’s health > began to decline, and given that Ian, Ryan and I were the only Canadian > employees, and our technical staff were centrally located to our data > centre locations, we decided on a remote-work structure in Canada. While > the Canadian filings ended in 2016, we still maintain personnel, a secure > storage facility, and we have always maintained a consistent mailing > address in Ontario where the public can contact the TrustCor Policy > Authority in writing for policy related enquiries and this is the same > address printed on TrustCor’s letterhead and within our CPS documents. > > > To directly address and assuage the public’s concern, we will replace the > word “Headquarters” with “Address” in future documentation. > > In the interest of transparency, we have additional storage, meeting > space, and technical operations (supporting full time employees) in > Phoenix, AZ, which is an audited location where our equipment and IT > process controls are reviewed annually. > > I have questions: could you clarify the possible existence of a US entity employing the persons in Phoenix Arizona, and its relation to the entities in Canada and Panama? In general I believe it's unusual for international businesses to directly employ people across borders, and usually set up a local entity wholly owned by the parent to engage in such activities. > ————————————— > > *To address Joel’s (University of Calgary/AppCensus) concerns,* > > *In Response to: "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].”:* > > We cannot comment on the activity of another company, as any comment would > be purely our speculation. > > Could you clarify the relationship between Vostrom Holdings and TrustCor, both now and in the past? > *In Response to: "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 SD**K [9].”:* > > We cannot comment on the activity of another company, as any comment would > be purely our speculation. > > > *In Response to: ""**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]*.”: > > We cannot comment on the activity of another company or individual, as any > comment would be purely our speculation. > > > *In Response to: "**Domains were registered by Vostrom: 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].”:* > > 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. In the early days of the long transition and upgrading > (porting to a different programming language) of the software from the > DecoyMail service to the MsgSafe.io service (which took years), these > domains were registered while the software was still pointed to the same > registrar account of the previous owner which owned many other domains > including others unrelated DecoyMail customer domains and also domains of > the registrar account owner. Even still, it was not even a > corporate/wholesale account, it was a personal account with a variety of > domains held by one of the original DecoyMail shareholders. The platform > was not officially relaunched for several years when it was announced as > MsgSafe.io as shown here: https://trustcor.com/news/12012016.php. Even > after relaunching it, several more years passed before all domains were > migrated to the production registrar, DNSimple, and we are not even certain > they were all migrated — some DecoyMail users did not transition their > accounts fully and some lookalike domains were not identified because they > were lookalikes or homoglyphs and not critical to the company branding > or functionality. > > > All domains registered through msgsafe (such as trustcor.co and also > trustcor.com), and any domain brought to msgsafe using the > bring-your-own-domain feature would contain msgsafe.io name server > records that point to either nsX.msgsafe.io or nsX.dnsimple.com, which > are synonymous, hosted at the same IP address, and are operated by > DNSimple. > > > *In Response to: "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”:* > > 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. > > You say "employee officers". What set of corporate officers is this? Why is it relevant to your ability to provide information on the relationship of these entities that the officers in question, who surely realized that they were doing the job at two different companies, were not employees? > *In Response to: "**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.”:* > > We are not now, and never have been, owned by any American company with > any names similar to those pointed out by the researchers. We have no idea > what those companies are or what are their purpose, but they are not > affiliated with our company or anyone known to us. Our business was > formed in Panama over 9 years ago and any paperwork filed this year was not > executed by our company. Our lawyer has instructed us not to point out the > subtle differences in names, spelling, dates of incorporation, or legal > territories in which corporate entities were formed, as litigation is a > potential outcome of this publication. > > I understand being from Canada you might not be familiar with US libel law. I suggest you get a lawyer who is before you brandy around threats like this. > *In Response to: "**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.”:* > > We find that most CAs don’t publicly disclose the locations of their CA > data centre location on the home page of their marketing websites. The > aspect of our business which operates the encrypted email product and > stores secure customer content, MsgSafe, has technical operations based > in Curaçao (hence the "geo-jurisdiction advantage”) whereas the CA > business unit has data centers located in Arizona. In the interest of trust > and transparency, to be clear, TrustCor’s CA business unit does > not perform key escrow services and therefore does not store customer > private-keys, as stated in our CPS. > > Let me spell out my understanding based on what's been said so far. TrustCor CA is a company in Canada, wholly owned and operated by TrustCor, an Panamanian company operating in a money laundering haven with weak rule of law. TrustCor also owns MsgSafe, which it operates in Curacao. But TrustCor CA isn't adverse to locating business operations in the US, a country which along with Canada has a functioning and trusted court system. So why exactly should I trust TrustCor with the safety of every site on the Internet? What's wrong with Canada or Arizona? Why Panama? Together with the reluctance to disclose funding and owners I can think of a few answers to this question, none of which are particularly encouraging for my trust in TrustCor. > *In Response to: "**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.”:* > > > MsgSafe.io’s platform can be utilized in a number of ways, including > using the e-mail forwarding features and not using the web-based interface > at all. It is impossible to speculate what you experienced or tested > without comprehensive knowledge of the account configuration, forwarding > addresses, user identities and contacts, and their associated GPG and > S/MIME certificates. > > As far as you not believing the product is offering adequate encryption > capabilities, let me first say that I do not want to drag the names of any > other encryption products or services through the mud. To address > your concerns, based on our teams exhausted research into many other > providers offering similar services, one basic rule applies; whether the > encryption or decryption functions are occurring on the client (often in > javascript) or on the server, the server is still storing and handling the > key material in the process. Our implementation is one of two commonly used > by secure messaging services and chosen for a few reasons. If encryption > occurs on the client then the key material is passed from the server to the > browser over TLS. If the encryption occurs on the server then the message > is transferred from the client to the server over TLS, then encrypted. As > the MsgSafe website explains, our team has found that implementing the key > material and encryption/decryption processing on the server provides > security without the additional processing requirement on the client. One > of the benefits of this implementation is that it allows slower/older > devices (phones) to utilize our mobile-first web experience (since, as we > previously mentioned, we abandoned development of a mobile app, which could > have done the encryption/decryption process on the mobile phone), while > also supporting desktop users. To be clear, at no point is data passed in > the clear while using the service, it is either encrypted with the user key > material or encrypted with industry-standard TLS. > > Many MsgSafe.io users never experience sending or receiving mail using > the web browser, meaning you’re only looking at one implementation of the > service that is probably the least used. > > Of course we can accept the possibility of a weakness in MsgSafe.io's > user interface, we take such reports very seriously, but we would be > surprised to find that to be the case here. If you still have questions or > doubts, we ask that you please file a bug report with MsgSafe.io directly > via their customer support channels. > > It is also important to note that MsgSafe.io and TrustCor’s CA do not > share development resources or infrastructure and are completely different > lines of business. > > > *In Response to: "**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.”:* > > When the domains were registered, it was also common for advertisers to > buy Google search keywords of their competitors as part of their SEO > marketing. > > This is not really relevant to typosquatting. At the time, it was perceived as a low-cost way for a small start-up e-mail > provider to direct a very small amount of traffic to MsgSafe.io’s new > privacy-focused email services. > > Perceived by who? It was not an attempt to mislead consumers in any way -- users very clearly > understood where they had been directed. It is not the company's stance or > best practice to register domain names similar to competitors, only > happened with a small number of domains, and did not occur again after 2016. > > The redirect is still up as are the registrations. It is 2022, quite some time after 2016. > > *In Response to: "**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 [email protected] > <[email protected]> is linked to the domains rodneyjoffe.com > <http://rodneyjoffe.com>, packetforensics.com <http://packetforensics.com>, > and decoymail.net <http://decoymail.net> [34]. Decoymail.net currently > redirects to msgsafe.io <http://msgsafe.io>.”:* > > It is public information 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. In the > early days of the long transition and upgrading (porting to a > different programming language) of the software from the DecoyMail service > to the MsgSafe.io service (which took years), these domains were > registered while the software was still pointed to the same registrar > account of the previous owner which owned many other domains including > others unrelated DecoyMail customer domains and also domains of the > registrar account owner. Even still, it was not even a corporate/wholesale > account, it was a personal account with a variety of domains held by one of > the original DecoyMail shareholders. The platform was not officially > relaunched for several years when it was announced as MsgSafe.io as shown > here: https://trustcor.com/news/12012016.php. Even after relaunching it, > several more years passed before all domains were migrated to the > production registrar, DNSimple, and we are not even certain they were > all migrated — some DecoyMail users did not transition their accounts fully > and some lookalike domains were not identified because they were lookalikes > or homoglyphs and not critical to the company branding or functionality. > > > ————————————— > > *To address Serge’s (Berkely/AppCensus) concerns,* > > *In Response to: “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…”:* > > Our company never published a production or supported version of the > MsgSafe mobile app containing the Measurement Systems SDK. Relative to the > tiny population of Beta product-testers (which were largely our own > employees) who chose to test a Beta version of the app containing that SDK, > I will add that during the development stages of MsgSafe’s BETA mobile app, > our developers sought out the help from 3rd party software services to > obtain better app analytics. We are aware that they evaluated other SDKs > and tools like Firebase, Bugsnag, etc. but they claimed to not help much in > troubleshooting and improving the app functionality across all device > manufacturers and OS versions. There was a time during this process where > they incorporated additional software developers to help with the issues we > were facing. Whether or not the SDK was added for a developer’s own > financial gain or otherwise is beyond us and we don’t care to speculate. > Again, the MsgSafe BETA mobile app was never released in a production > supported version and has been abandoned for years, and we can confirm the > mobile-first web UI, which is the only supported mobile interface in-use > today and for the last few years, which does not contain any SDK from > anyone. > > > As far as how the MsgSafe mobile app obtained an “unobfuscated version” of > the SDK? It is not our place to speculate, but it only makes sense that any > company would provide updates to their software over time. The third-party > app archive website containing MsgSafe’s APK, as referenced in the > researcher’s post, is over 3 years old. It should come as no surprise that > the software found there doesn’t match up exactly to the software found in > apps they reported about in April 2022. Our developers probably didn’t even > notice subtle changes like this because it’s not our practice to reverse > engineer other company’s software and violate license agreements. > > Finally let me note that the general evasiveness, thinly veiled legal threats, and contemptuous attitude this entire email contains have convinced me that TrustCor does not have the appropriate attitude for a CA. Rather than openly share information to assuage the community and rebuild that most precious and delicate material of human relations, trust, Rachel has chosen to obfuscate, feign ignorance and give partial answers to some very serious questions. Sincerely, Watson Ladd -- Astra mortemque praestare gradatim -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CACsn0ckbai_R%3D2nsK7BHVY%2BDcCc1xxb5F1kJytoV4g8m7-fcrw%40mail.gmail.com.
