@Watson Ladd, Again,
We agree ssl.com to cancel free certificates. It means there aren't only free certificates we're providing. But also paid certificates, if only annually(1 year) cert been cancelled it be fine we can take it, but there are many multiple year subscription purchased by our users(including some OV certs). If you bought something with a period of many years, but delivered it on an annual basis, and the merchant ran away after one year, would you defend your consumer rights? It should sounds fair to refund remaining subscriptions' fee if cancelled? Especially we haven't to proof OV or EV is associated with HiCA because the CA's OV/OV won't become issued automatically after domain names been validated. so HiCA didn't implement them ever. We agree to revoke free certificates because our integrating on HiCA, certificates provided were only free. No CA's paid product was integrated ever. We mean we do not agree no additional proceeding for the subscriptions/(certificates to be issued) more than 1 year after revoked personal word from me, Mr Ladd, It is recommended not to do serious injuries because that are not gentlemen. Did you see someone disclose that the server was hacked after run `acme.sh --issue --server https://acme.hi.cn/directory` on the Internet, or did you get a completely offensive injection code? We can accept a source code audit of the project w/ full git log and databases binlog if you're willing to bear the cost and we think it's fair because your keyboard swearing didn't pay for anything but electricity so you want to blame please prove it, if exists and we shall keep our ears open. 在2023年6月14日星期三 UTC+8 23:38:07<Watson Ladd> 写道： > On Sun, Jun 11, 2023 at 6:42 AM Xiaohui Lam <inao...@gmail.com> wrote: > > > > We agree with SSL.com canceling the 90-day certificate customers under > Quantum subCA, but we object to the annual customer service payment. > > Should SSL.com refund some of the certificates because they were > multi-year subscription certificates purchased? > > > > If not, why not cancel the product purchase entrance for more than 365 > days on your website and interface? > > > > It's likely a fraud in business. > > That's an interesting word to throw around for someone who has > committed what looks to all the world like a CFAA violation. I'm > struggling to understand why you would think this was acceptable > conduct to use an RCE in issuance, in short running code on sensitive > machines without user consent. > > Furthermore the CA business is built on trust. SSL.com is doing the right > thing. > > Sincerely, > Watson Ladd > > > > > It might should not be involved in this dev security group, but we wanna > some expanding of this topic with other resellers and CAs in the industry. > > 在2023年6月10日星期六 UTC+8 02:17:26<Thomas Zermeno> 写道： > >> > >> 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 > >> > >> 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-secur...@mozilla.org" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to dev-security-po...@mozilla.org. > > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/f8c61c43-44df-45af-b809-6692cc13edb0n%40mozilla.org > . > > > > -- > Astra mortemque praestare gradatim > -- 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/9a255c7d-0de0-47e8-9249-50f2ffd36fa4n%40mozilla.org.
