On Tue, Oct 14, 2025 at 05:19:30AM -0700, Alvin Wang wrote: > 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.
No, SHECA does not "always strictly adhere", as SHECA has violated BR 6.1.1.3. Please do not engage in marketing hyperbole in a technical forum, it does not benefit SHECA in any way, and only serves to indicate that SHECA does not take these matters seriously enough to engage in clear and honest communication with the community. > 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). As a member of the Mozilla community, SHECA should already be aware that it is not possible to "appl[y] for a delayed revocation", as a great deal of prior discussion, and Mozilla's own policies, make abundantly clear. > 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. To be frank, this document does not improve my opinion of SHECA's security engineering posture. It mentions that HS256 is the default algorithm, even though that algorithm uses a shared key (with no indication of where this shared key comes from), then later in the "Signature" section it specifically acknowledges that "The private key should only be accessible to the user", yet the document also states that "SHECA generates public and private keys in the order system", which violates this principle. Further, there appears to be confusion about where the JWT is even generated, as the document states "After receiving the JWT from the server", which would strongly imply, if a private key was used to produce the signature, that the private key is being stored, or is at least continuously accessible in some way, by the server. I repeat: this is *not* the way that private keys are used in JWT by "Internet companies as a security verification method". Examples of how they are used can be found in specifications like OIDC, where the public key is provided so that the JWT can be verified, without exposing the private key to disclosure to *any* other party. > I also look forward to further > communication with you through this document to reach a consensus on the > relevant details. If SHECA wants my professional expertise, I am available for commercial consulting. Given that this poor practice around key handling for JWTs, whilst deeply concerning with regards to SHECA's security practices overall, does not directly impact Mozilla or the BRs, it's probably not appropriate to continue discussing this point in this forum, anyway. - 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/53d1a20c-bf5f-45d5-9980-ad60f7792269%40mtasv.net.
