4 ms·

One one hand i agree that being defensive is warranted given the accusation, especially considering most of the claims appear to be related to an entirely diffe

One one hand i agree that being defensive is warranted given the accusation, especially considering most of the claims appear to be related to an entirely different product than their CA business. The bit where someone goes to great length to demonstrate how they email isn't e2ee is especially jarring. That said, it appears mozilla's decision is founded not on their response in the thread, but on the fact that Trustcor basically is a root CA for the sole reason that they provide a useful service in the exact product being shown as untrustworthy. If the only reason is their email service, and their email service can't hold up to scrutiny (including promising e2ee and not actually providing it, and having poor development security practices) then why do they have root CA power in 99% of client devices? in my opinion, their email service didn't warrant such inclusion to begin with, even if the service was sound, and that's not accounting for their weird corporate ties (which may be legitimate, tbf).

dcow 4y ago
Rachel stated that TrustCor CA has many customers that are not the email service. Because this isn’t a court, discovery won’t tell us if that is, in fact, true or not. But if it is, then it seems completely normal.
- themoonisachees 4y ago
  Moz's decision isn't based on the costumer base, it's based on "what does you being a root CA provide?". Their email service was listed as the primary reason they should be a root CA (regardless of other eventual costumers) and if the email service isn't sound then their primary reason is moot.
  - dcow 4y ago
    That’s fair and I do agree with that line of reasoning. You don’t need a CA to run a mail service anymore. Perhaps we should audit all of the CA value statements and weed out dated entities…
- otikik 4y ago
  I don't think those other customers share offices or personnel with TrustCor tough.
- tialaramex 4y ago
  Although m.d.s.policy contributors might represent other uses of the Web PKI, the browser vendors (or at least Microsoft, Mozilla and Google) are primarily interested in web browsers, and it's unlikely that "But look at these SQL Servers" for example is a compelling objection to measures whose primary goal is to secure the web. And in practice, on the web you're baking SCTs into the certificates (technically sophisticated customers might buy certificates with no SCTs because they know what they're doing, but that's a speciality product, lotta people buy gasoline every day, but not too many need barrels of crude oil, if you claim 2 million distinct customers served daily but then say they're all buying crude oil I just don't believe you). To get working SCTs the (pre-)certificate needs to be logged at one of a few dozen trusted Certificate Transparency logs. Which means there's a public record of every such certificate, who issued it and when it was logged. While this is indeed not a court and doesn't have "Discovery" the CA agreements do require the CA to provide Mozilla and other vendors with complete records of certificates they're interested in, these days that is often provided in the form of crt.sh links because hey, the (pre-)certificates† were in the logs anyway, but it's compliant to provide the data as ZIP files or whatever -- if there is such data and you have it. So, no, independent researchers can get a pretty good idea by just inspecting a public log view, and the browsers can insist on getting the exact answer if they want it, unless of course TrustCor doesn't care about being distrusted. † You aren't required to log the certificate as well as a pre-certificate but in many cases CAs do that too. Modern rules are clear that the existence of the (non-working) pre-certificate is assumed to imply the existence of the corresponding certificate even if you claim the certificate was never actually issued.

dcow 4y ago

Rachel stated that TrustCor CA has many customers that are not the email service. Because this isn’t a court, discovery won’t tell us if that is, in fact, true or not. But if it is, then it seems completely normal.

themoonisachees 4y ago
Moz's decision isn't based on the costumer base, it's based on "what does you being a root CA provide?". Their email service was listed as the primary reason they should be a root CA (regardless of other eventual costumers) and if the email service isn't sound then their primary reason is moot.
- dcow 4y ago
  That’s fair and I do agree with that line of reasoning. You don’t need a CA to run a mail service anymore. Perhaps we should audit all of the CA value statements and weed out dated entities…
otikik 4y ago
I don't think those other customers share offices or personnel with TrustCor tough.
tialaramex 4y ago
Although m.d.s.policy contributors might represent other uses of the Web PKI, the browser vendors (or at least Microsoft, Mozilla and Google) are primarily interested in web browsers, and it's unlikely that "But look at these SQL Servers" for example is a compelling objection to measures whose primary goal is to secure the web. And in practice, on the web you're baking SCTs into the certificates (technically sophisticated customers might buy certificates with no SCTs because they know what they're doing, but that's a speciality product, lotta people buy gasoline every day, but not too many need barrels of crude oil, if you claim 2 million distinct customers served daily but then say they're all buying crude oil I just don't believe you). To get working SCTs the (pre-)certificate needs to be logged at one of a few dozen trusted Certificate Transparency logs. Which means there's a public record of every such certificate, who issued it and when it was logged. While this is indeed not a court and doesn't have "Discovery" the CA agreements do require the CA to provide Mozilla and other vendors with complete records of certificates they're interested in, these days that is often provided in the form of crt.sh links because hey, the (pre-)certificates† were in the logs anyway, but it's compliant to provide the data as ZIP files or whatever -- if there is such data and you have it. So, no, independent researchers can get a pretty good idea by just inspecting a public log view, and the browsers can insist on getting the exact answer if they want it, unless of course TrustCor doesn't care about being distrusted. † You aren't required to log the certificate as well as a pre-certificate but in many cases CAs do that too. Modern rules are clear that the existence of the (non-working) pre-certificate is assumed to imply the existence of the corresponding certificate even if you claim the certificate was never actually issued.