Hi Xiaohui, I think you may have misunderstood my message. What I meant to convey was that I am skeptical of your intention to resell your own CA for a dissolved Ltd. that was not subject to having its certificate revoked. We believe that this practice is uncommon for a reseller in such a case.
Please understand that my message was not intended to be hateful towards you or your team. If you believe that this was an honest mistake, please reply to this thread with more details. The community values transparency and trust, and we would be happy to hear your perspective. Best regards, Zephyr Lykos On Saturday, June 10, 2023 at 1:08:08 AM UTC+8 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/8a96f803-7473-4a82-9c4c-041edb2ee93bn%40mozilla.org.
