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.
2. Which BR Regulation Should be Applied to the Revocation Reason 2.1 Regarding Bastian's Description "According to the definition of 'Key Compromise' in the BR, is the CA considered an unauthorized person? If so, this would trigger revocation within 24 hours in accordance with 4.9.1.1." These API were authorized by partners when they were provided to them. Furthermore, when partners provided these methods to subscribers, they also signed corresponding subscriber agreements to obtain user authorization. Therefore, SHECA believes that the reason for revocation in this incident does not apply to the third point of 4.9.1.1. 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)). 2.3 Summary SHECA acknowledges that the aforementioned two interfaces do violate the following rules in BR 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." As well as BR 9.6.3: "The Applicant is obligated and warrants to take all reasonable measures to ensure control, confidentiality, and proper protection at all times of the private key corresponding to the public key included in the requested Certificate (as well as any related activation data or devices, such as passwords or tokens);" SHECA believes that the most appropriate revocation reason for this case is per 4.9.1.1, point 16. Although there is no risk in the method SHECA uses to generate CSRs and private keys, the act of SHECA providing APIs for generating CSRs and private keys does carry certain risks. In the event that SHECA's system is compromised, it could lead to the leakage of subscribers' private keys. SHECA will comply with BR regulations, revoke all certificates applied for through the above two API interfaces within five days, and require users to generate new CSRs and private keys to reapply for certificates. SHECA will open a case on Bugzilla to report follow-ups. Please feel free to ask if you have any other questions. On Wednesday, October 8, 2025 at 7:19:54 AM UTC+8 Matt Palmer wrote: > On Tue, Oct 07, 2025 at 04:52:56AM -0700, Alvin Wang wrote: > > SHECA provides partners with public and private keys for authenticating > > their API requests. > > That seems like a terrible idea, but would appear to be outside the remit > of the BRs. > > > /open-api/v2/order/download-zip > > Function: Download certificates in all formats > > Subscriber-provided parameters: Private key and order number > > ... again, doesn't appear to be a BR violation, but seems to be an > even more terrible idea. > > > /open-api/v2/tools/gen-csr > > Function: Generate a certificate request (CSR) > > Subscriber-provided parameters: None > > SHECA returns: Certificate request (CSR) and private key. > > 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. > > - 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/a39d9509-de53-494b-a61a-cf8bec0a2daan%40mozilla.org.
