Hi Matt, Thank you very much for your attention and support regarding this incident! As a member of the CA/Browser Forum community, SHECA always strictly adheres to relevant community standards. This is our consistent principle. Regarding your first question, I have compiled a detailed document (https://github.com/SHECA-Alvin/CASE/blob/main/jwt.md) that details SHECA's approach to using public and private keys for interface authentication. I hope it will be helpful for your reference. I also look forward to further communication with you through this document to reach a consensus on the relevant details.
Regarding the certificate revocation you mentioned, SHECA is currently working on the matter and has applied for a delayed revocation (https://bugzilla.mozilla.org/show_bug.cgi?id=1994051). We will promptly update you on any further progress. If you have any further questions, please feel free to contact us. Best regards！ Alvin.Wang On Sunday, October 12, 2025 at 7:38:27 AM UTC+8 Matt Palmer wrote: > On Wed, Oct 08, 2025 at 05:25:33AM -0700, Alvin Wang wrote: > > Hi,everyone! > > 1. Reply to Matt's comment > > SHECA adopted this solution to provide partners with public and private > > keys for identity authentication, and used JWT to verify partners' API > > requests, because it can effectively prevent unauthorized data access and > > ensure security. This authentication solution is widely used by Internet > > companies as a security verification method for external API provision. > > That's why this solution was considered by SHECA. > > Having the authentication provider generate the private key is not, to > the best of my knowledge, a solution widely used by Internet companies. > > > 2.2 Regarding Matt's Description > > "If that CSR contains the public key corresponding to the returned > private > > key (and I'm not sure how it could be anything else), and that CSR is > later > > used by SHECA to issue a publicly-trusted certificate that contains > > serverAuth or anyEKU, that would appear to be a BR violation, per the > last > > paragraph of 6.1.1.3: > > > > If the Subscriber Certificate will contain an extKeyUsage extension > > containing either the values id-kp-serverAuth [RFC5280] or > > anyExtendedKeyUsage [RFC5280], the CA SHALL NOT generate a Key Pair on > > behalf of a Subscriber, and SHALL NOT accept a certificate request using > a > > Key Pair previously generated by the CA. > > This violation requires revocation within 24 hours, per 4.9.1.1, point > 4." > > > > SHECA believes that 4.9.1.1 point 4 is not applicable to this case. This > is > > because the generation method of the public and private keys has not been > > compromised, and external attackers cannot calculate the subscriber's > > private key from the public key through any known methods (including > those > > mentioned in 6.1.1.3(5)). > > SHECA can believe what it likes, but the BRs very clearly state that > revocation within 24 hours is required. > > - Matt > -- 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 visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/89be2262-f24e-4db6-8274-46b405b593e9n%40mozilla.org.
