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/cfd14ada-48ff-45d9-a164-2c83c8d2f964%40mtasv.net.
