On Wed, Oct 08, 2025 at 05:25:33AM -0700, Alvin Wang wrote:
> 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.

Having the authentication provider generate the private key is not, to
the best of my knowledge, a solution widely used by Internet companies.

> 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)).

SHECA can believe what it likes, but the BRs very clearly state that
revocation within 24 hours is required.

- 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/b47a26fc-385d-43ef-ab4d-d3973c60a52e%40mtasv.net.

Reply via email to