Hi Ryan, Thank you very much for your professional reply. SHECA has forwarded the code implementation issues you mentioned to our R&D department, who are currently evaluating a corrective action plan. Once the corrective action is completed, SHECA will release the complete code on GitHub for community review.
Once again, thank you for your support and assistance! On Saturday, October 4, 2025 at 5:42:06 AM UTC+8 Ryan Hurst wrote: > Thanks for sharing the details and code. > > From my perspective, this isn’t inherently non-compliant with the TLS > Baseline Requirements. The relevant section is 6.1.1.3 – Subscriber Key > Pair Generation: > > 6.1.1.3 Subscriber Key Pair Generation > > If the CA generates the Key Pair on behalf of the Subscriber, then the CA > SHALL NOT archive the Subscriber Private Key. The CA SHALL encrypt the > Subscriber Private Key for transport to the Subscriber. The CA SHALL NOT > have access to the Subscriber's Private Key once the Subscriber has taken > possession of it. > > If the Subscriber generates the Key Pair, the CA MUST use a process that > verifies that the Key Pair meets the minimum requirements of Section 6.1.5 > and SHALL reject CSRs that are incapable of being used to issue a > certificate that complies with these Requirements. > > Nothing in the BRs prohibits a CA from distributing software or code that > performs client-side key generation. A JavaScript-based CSR tool isn’t > automatically out of scope. > > However, this implementation is not production-grade: > > - > > Weak entropy fallback, the code relies on jsrsasign for key > generation. While modern browsers support window.crypto.getRandomValues(), > the implementation lacks proper handling when this isn’t available. It can > silently fall back to weak sources like Math.random() and time-based > seeding. The correct behavior is to fail closed if WebCrypto is > unavailable. > - > > Hand-rolled JavaScript cryptography is fragile; timing side channels, > integer handling quirks, and lack of formal verification introduce > significant risk. WebCrypto (SubtleCrypto) exists precisely to avoid these > problems, with constant-time native implementations. Not using it means > choosing a weaker, more vulnerable approach when a stronger mechanism is > built in. > - > > Deprecated code path, the CSR helper shown (CSRUtil.newCSRPEM) is > deprecated within jsrsasign. Deprecated paths may contain unserviced > security defects or bugs, making them unsuitable for a CA-promoted tool. > - > > Plaintext key delivery, the tool delivers the private key to the user > as plaintext PEM. While not strictly prohibited by the BRs when the > subscriber generates the key pair, this is risky in practice. Keys left in > download folders or synced to backups are routinely lost track of. When we > built our STIR/SHAKEN CA at Martini Security, we required encrypted > private-key downloads for this reason—it was the only reliable way to > prevent inevitable sprawl and exposure. > > In my view, the minimum bar for subscriber-side CSR generation should be: > > 1. > > WebCrypto for keygen and entropy (SubtleCrypto.generateKey + > crypto.getRandomValues). Fail closed if unavailable. > 2. > > Encrypted private-key export (PKCS#8 EncryptedPrivateKeyInfo with > PBES2/PBKDF2). > 3. > > Auditable and pinned build: strict CSP, SRI on bundles, offlineable > package for transparency. > 4. > > Reject CSRs that don’t meet minimum key strength per BR 6.1.5. > > Bottom line from my perspective is that this isn’t a direct BR violation, > but as implemented, it is not the kind of key-generation flow a publicly > trusted CA or reseller should provide. If a CA chooses to offer such a > tool, it needs to be held to the same standard of care as any other > critical part of the certificate issuance process. > > Ryan Hurst > > On Fri, Oct 3, 2025 at 10:50 AM Alvin Wang <[email protected]> wrote: > >> Hi, Ryan. >> >> The following is SHECA's response to your question: >> >> Technology Used >> SHECA uses JavaScript code to implement the relevant encryption >> functions. The relevant core code is attached for your reference. >> >> Code Execution Environment >> All encryption-related operations are performed using JavaScript in the >> client browser. Specifically, when the client submits a certificate >> request, JavaScript code is called to generate the required encrypted data. >> Therefore, no JavaScript server-side processing is involved. >> >> The core code is attached for further review and optimization as needed. >> >> -- >> 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/c3da349d-3c96-4a6e-8ae9-29e6eaf302b7n%40mozilla.org >> >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c3da349d-3c96-4a6e-8ae9-29e6eaf302b7n%40mozilla.org?utm_medium=email&utm_source=footer> >> . >> > -- 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/1e40cedc-a5bb-4259-a92e-4c30c6c44e54n%40mozilla.org.
