Is this an official statement from ssl.com? If so can you please provide proof that madcarr...@gmail.com is authorized to speak on behalf of ssl.com ?
Seriously, why do all these CA's lack the ability to host their own email? On Fri, Jun 9, 2023 at 12:17 PM Thomas Zermeno <madcarr...@gmail.com> wrote: > We would like to clarify that SSL.com discontinued issuing Quantum certs > in 2022, and haven't issued any certs from the Quantum branded ICAs in > 2023. Furthermore, there is absolutely no association between HiCA and > SSL.com. In fact, only through the recent acme.sh RCE public discussions > were we made aware of the existence of HiCA. > > As a result, we took the initiative to further investigate and discovered > that QUANTUM CA LIMITED dissolved on November 1, 2022. We were not notified > about this change by Quantum. > > Based on this fact, we plan to revoke the Quantum branded subCAs and all > associated end-entity certificates within 7 days, as mandated by section > 4.9.1.2 of our CP/CPS. > > Regards, > > Tom > SSL.com <https://ssl.com> > > On Friday, 9 June 2023 at 12:08:08 UTC-5 Xiaohui Lam wrote: > >> Thanks John to share this topic to the dev-security forum. >> >> This is HiCA founder, let me to explain your concern, Mr John , >> the RCE is fully used to finish the challenge which validated by CAs, in >> another word, the ACME.sh-enrolled certificates which passing this RCE, it >> does compliant with each CA's BR validation requirements. CA did nothing >> wrong. And also by this trick can enroll any CA's certificate before >> acme.sh fix patch. >> >> and to Mr @mochaaP, you said to punish our team, we're NOT a public CA or >> private CA(in my understanding, a CA must manage a or more PKI >> infrastructure physically), [3]so the clarify relationship to HiCA w/ >> QuantumCA is no necessary, but we still told we runs HiCA inside QuantumCA >> project's source code, it's a sub-application inside it. >> >> I agree @Andrew's opinion, CAs shouldn't take any responsibilities to the >> RCE incidents. or there are hundreds acme-tools for CAs need to concern. >> 在2023年6月10日星期六 UTC+8 00:43:47<mochaaP> 写道： >> >>> Hello, >>> >>> Although HiCA is not a CA itself, the person own HiCA seems also owns >>> (or at least works for) Quantum CA[1][2]. they also confirmed that Quantum >>> CA is operated by both their team and SSL.com team[3]. >>> >>> I think this probably is not as simple as a white-label intermediate CA >>> being abused, rather a CA that resells their own product to themselves to >>> prevent being punished for bad behaviors. >>> >>> [1]: https://github.com/xiaohuilam (see "Pinned" section) >>> [2]: https://github.com/quantumca (see "People" section) >>> [3]: >>> https://github.com/acmesh-official/acme.sh/issues/4659#issuecomment-1584546150 >>> (note that this person never clearified their relationship with Quantum CA >>> and only replied with "So this isn't the evidence to proof HiCA is a CA >>> which managed PKI.") >>> >>> Regards, >>> Zephyr Lykos >>> >>> On Friday, June 9, 2023 at 9:04:34 PM UTC+8 Andrew Ayer wrote: >>> >>> On Fri, 9 Jun 2023 05:42:22 -0700 (PDT) >>> "John Han (hanyuwei70)" <hanyu...@gmail.com> wrote: >>> >>> > Here is the story. >>> > https://github.com/acmesh-official/acme.sh/issues/4659 >>> > >>> > Seems like they exploited acme.sh and let user to evade certificate >>> > issuing procedure. >>> > >>> > Do we need to discuss this? >>> >>> The party in question (HiCA/QuantumCA) is not a certificate authority, >>> and I don't see any evidence that the actual CAs in question evaded any >>> validation requirements. >>> >>> HiCA/QuantumCA is just acting as an intermediary between subscribers >>> and the issuance APIs operated by actual CAs[1]. Literally anyone can >>> do this and do monumentally stupid/insecure things; it's not productive >>> to have a discussion every time this happens. >>> >>> Regards, >>> Andrew >>> >>> [1] It's true they have a reseller relationship with ssl.com, who are >>> operating a white-label intermediate CA with "QuantumCA" in the >>> subject, but HiCA/QuantnumCA are also fronting other CAs, including >>> GTS, which doesn't require a reseller agreement to access their free >>> ACME API, so I don't see that aspect as being productive to discuss >>> either. >>> >>> -- > 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/528b5350-1a32-4730-8e7b-16644d135274n%40mozilla.org > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/528b5350-1a32-4730-8e7b-16644d135274n%40mozilla.org?utm_medium=email&utm_source=footer> > . > -- Kurt Seifried (He/Him) k...@seifried.org -- 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/CABqVa38id3nahtskXYuWbCKJuCisCbgWfXHJxDxRVd2BjQ8W4Q%40mail.gmail.com.
