All, While we are incredibly disappointed with this decision, we are not going to waste anyone's time with a response to the removal right now.
>From a practical standpoint, Microsoft seems to have set the distrust date for >TrustCor's roots to November 1, 2022 instead of November 30, 2022, which >impacts over 1,200 customers who reasonably acquired a TLS certificate from >TrustCor between November 1 and November 30. While immaterial to us in this >group of readers and vendors, the distinction is important to these customers. Microsoft gave us no advance notice of this decision and we have reached out to Microsoft directly ourselves, but in this public forum if any Microsoft employees can make this change to reasonably mirror Mozilla's decision, it would make a difference to these people. Thank you, Rachel > On Nov 30, 2022, at 5:01 PM, Kathleen Wilson <[email protected]> wrote: > > All, > > > I appreciate the thoughtful and constructive input that has been provided in > this discussion. > > > Based on the findings that were shared in this discussion thread > <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/etbBho-VBQAJ> > and the responses from Trustcor’s Vice President of CA Operations, we > believe that the following statements directly pertain to TrustCor’s position > as a CA in Mozilla’s Root Program and have not been disputed: > > > Measurement Systems is a company that has engaged in the distribution of an > SDK containing malware to Android users. [1] > > TrustCor operated a mail encryption product called MsgSafe which is > operationally tied to its CA unit. Specifically > > 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] > > MsgSafe relies upon TrustCor’s role as an SMIME CA for its operation. [3] > > MsgSafe is highlighted prominently in TrustCor’s own benefit statement of its > inclusion in Mozilla’s Root Program. [4] > > An early, unobfuscated version of the malware SDK produced by Measurement > Systems was included in TrustCor’s MsgSafe beta Android application. [5] > > Measurement Systems and TrustCor have in the past had shared corporate > officers, operational control and technical integrations: > > Measurement Systems and TrustCor shared corporate officers until 2021 (or > later). [6] > > Ian Abramowitz, was active in the operation of TrustCor as CFO and an officer > of the companies which owned both TrustCor and Measurement Systems. [7] > > A developer hired by Trustcor had unobfuscated access to the source code of > Measurement System’s malware SDK and write access to the source code of the > MsgSafe application and hosting environment. [8] > > There is no evidence of TrustCor mis-issuing TLS or SMIME certificates. > > > There are suggestions of additional links between the companies whose factual > basis has neither been fully substantiated nor refuted. For example, Ryan > Abramowitz was previously the CEO of both TrustCor and Measurement Systems. > Ryan’s LinkedIn profile > <https://www.linkedin.com/in/ryanabramowitz/details/experience/> previously > listed: “Co-Founder / Digital Strategist TrustCor Systems · Jun 2013 - Dec > 2016. And D&B > <https://www.dnb.com/business-directory/company-profiles.measurement_systems_s_de_rl.fe1d33ee8c1ff9a19bcc9c5b877cb483.html> > (a reputable business records company) shows Ryan as CEO of Measurement > Systems. > > > 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. > > > In line with our policies, Mozilla weighs the risks and benefits to end-user > security when deciding whether a CA should be a member of our Root Program. > Ordinarily, Mozilla would not directly evaluate the benefit of the CA owner’s > other products when considering whether a CA should be a member of our Root > Program. However, Trustcor’s quantifying value statement > <https://04815712939683618271.googlegroups.com/attach/5f0bb22670488/TC_CA-Quantifying_Value_Statement.pdf?part=0.0.1.1&view=1&view=1&vt=ANaJVrG2BuuvwDdec09YHxygEuvjnuyYmLHHoNV8LQVTpx7JtolgguYv4uhr8cSHroAxjoeeyeEhqtCs6_fy3vTLxEnpcKNTuHv6PlqecBsUv1VXcgQx8XU> > rests heavily on the value of MsgSafe which has suffered from a number of > problematic behaviors [9] that undermine the value proposition of MsgSafe, > and therefore undermine the purported benefits for the TrustCor CA to be a > member of our Root Program. > > > 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 > <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/WJXUELicBQAJ>, > we intend to take the following actions: > > 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. > > Remove those root certificates from Mozilla’s root store after the existing > end-entity TLS certificates have expired. > > > If evidence is found that the CA has mis-used certificates or the CA > backdates certificates to bypass the distrust-after settings, then we will > remove the root certificates from Mozilla’s root store in an expedited > timeline, without waiting for the end-entity TLS certificates to expire. > > > Mozilla will not accept cross-signing of the existing TrustCor root > certificates by other root CA Operators in Mozilla’s root store. If TrustCor > chooses to become a subordinate CA of another root CA Operator in Mozilla’s > root store, then all domain and email address ownership verification and > certificate issuance must be performed on the systems operated by the root CA > Operator. I.e. The domain and email address ownership verification and > certificate issuance must not be performed on systems operated by the > TrustCor CA. > > > Mozilla would like to thank the researchers who brought this to our and the > community’s attention, as well as the contributions from other members of the > community. > > > Thanks, > > Kathleen > > > References: > > > [1] As reported in the Wall Street Journal, April 2022: > https://archive.ph/AuNOy <https://archive.ph/AuNOy>. > > > [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.com/news/02052016.php > > <https://web.archive.org/web/20221108224150/https://trustcor.com/news/02052016.php>. > > > [3] Rachel McPherson’s response > <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/iARnIrvwBQAJ> > to this thread on the 18th November 2022 states “MsgSafe.io > <http://msgsafe.io/> > integrates with TrustCor’s S/MIME certificate API for issuance of S/MIME > certificates”. Further, TrustCor’s quantifying value statement > <https://04815712939683618271.googlegroups.com/attach/5f0bb22670488/TC_CA-Quantifying_Value_Statement.pdf?part=0.0.1.1&view=1&view=1&vt=ANaJVrFIg25sIA5Zy1h9H20_FgvDgmM1Jz9W9cb8a4u3js8lVGuZVchTiqGqEomvLlEiAHyoml1ZqTTXO4S2wc5CdFSpDrUNKVfeo_IoYWBLzFAuhsXw8e8> > highlights that “While that might be achievable through partnership, as has > been the case historically with S/MIME, business challenges and economics > hinder widespread adoption which makes our continued root program membership > absolutely critical.” > > > [4] TrustCor’s quantifying value statement > <https://04815712939683618271.googlegroups.com/attach/5f0bb22670488/TC_CA-Quantifying_Value_Statement.pdf?part=0.0.1.1&view=1&view=1&vt=ANaJVrFIg25sIA5Zy1h9H20_FgvDgmM1Jz9W9cb8a4u3js8lVGuZVchTiqGqEomvLlEiAHyoml1ZqTTXO4S2wc5CdFSpDrUNKVfeo_IoYWBLzFAuhsXw8e8>, > under the heading “What Kind of Benefits can Your CA provide to Mozilla?”. > > > [5] Technical analysis (1 > <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/u4KLEA6YBQAJ>, > 2 > <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/6uYLVgWaBgAJ>) > produced by Serge Egelman. The inclusion of the malware was acknowledged in > Rachel McPherson’s initial response > <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/iARnIrvwBQAJ> > and follow up responses > <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/Q5GAYoTSBgAJ> > as well as providing further details on how it came to be included. > > > [6] The identical corporate officers were acknowledged in Rachel McPherson’s > initial response > <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/iARnIrvwBQAJ> > and confirmed in a company document submitted privately by Rachel to Mozilla. > > > [7] Ian Abramowitz is described as the CFO of TrustCor on their website > <https://web.archive.org/web/20221108223409/https://trustcor.com/leadership> > and Rachel McPherson’s initial response > <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/iARnIrvwBQAJ> > notes “They are strictly passive investors, with the exception of Ian > Abramowitz”. In a company document submitted privately by Rachel to Mozilla, > Ian Abramowitz signs an agreement with TrustCor on behalf of both CHIVALRIC > HOLDING COMPANY LLC and FRIGATE BAY HOLDINGS LLC. > > > [8] See [5] and Rachel McPherson’s response > <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/Q5GAYoTSBgAJ> > on 21st November 2022, referencing findings from their software revision > control system and their forensic investigation of the an1.msgsafe.io > hostname and saved VM image. > > > [9] Including, but not limited to: 1) the malware SDK produced by > Measurement Systems was included in MsgSafe’s beta Android application. [5] > 2) For a period of time, user data was transmitted from MsgSafe’s beta > Android application to a server operated by Trustcor, before being forwarded > on to a third party. [10] 3) MsgSafe’s web application transmits user > messages to MsgSafe’s servers in plaintext, even though MsgSafe is advertised > as offering end to end encryption. [11] > > > [10] Rachel McPherson’s response > <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/Q5GAYoTSBgAJ> > on 21st November 2022, referencing TrustCor’s forensic investigation of the > an1.msgsafe.io hostname and saved VM image. > > > [11] End to end encryption is widely understood to mean that only the sender > and receiver of a communication should be able to read or modify the > messages, excluding access by third parties which operate servers or other > intermediary network services. MsgSafe’s website > <https://web.archive.org/web/20221130011310/https://www.msgsafe.io/> > highlights the provision of end to end encryption, including the statement > “MsgSafe.io cannot read your email.”. Technical investigations by members of > the community (1 > <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/etbBho-VBQAJ>, > 2 > <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/09ppQcZnCgAJ>) > confirm that in fact the webmail client transmits purportedly encrypted > messages in plaintext to the server and that the server is able to recover > the plaintext of those messages without the user’s password. Rachel > McPherson’s initial response > <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/iARnIrvwBQAJ> > describes this behavior as intentional, noting: “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”. > > -- > You received this message because you are subscribed to a topic in the Google > Groups "[email protected]" group. > To unsubscribe from this topic, visit > https://groups.google.com/a/mozilla.org/d/topic/dev-security-policy/oxX69KFvsm4/unsubscribe > > <https://groups.google.com/a/mozilla.org/d/topic/dev-security-policy/oxX69KFvsm4/unsubscribe>. > To unsubscribe from this group and all its topics, send an email to > [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/62669320-d923-4339-b557-9e2bfe0f9f52n%40mozilla.org > > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/62669320-d923-4339-b557-9e2bfe0f9f52n%40mozilla.org?utm_medium=email&utm_source=footer>. -- 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/734DF23C-4260-44FC-A765-5A9CE00B67C5%40trustcor.ca.
signature.asc
Description: Message signed with OpenPGP
