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/CALVZKwYrTzH8GmjwDm4NuacYT9ZS87MOuXdEiX4%2Bd1HNMFM0Zg%40mail.gmail.com.
