On Wed, Dec 22, 2021 at 2:41 PM Corey Bonnell <[email protected]> wrote:
> Do you agree that this is the goal of the requirements, or do you see it > differently? > I’m not sure I understand the question here, or it’s bearing on the compliance aspect. Could you help me understand how this is compliant with the requirements written? It sounds like, based on the question you posed, that the answer is “This doesn’t comply with the BRs, but might help achieve the presumptive goal.” That’s not to say that’s not an interesting area worth exploring, if the goal is to change the requirements, but I’m not sure it addresses the immediate issue here? If you believe (as your later reply suggests), that it complies, perhaps you can add more detail about how you see the private key usage being acceptable here, when considering doppelgänger certificates being - and remaining - in scope, regardless/independent of the BasicOCSPResponse. Recall: the core issue is the use of the private key, and the certificate(s) associated with that private key. Doppelgängers of self-signed certificates - that is, certificates with the same subject, issuer, and subject key - are all intrinsically linked together in scope, because each signed each other, and that’s key to understanding this issue. The BasicOCSPResponse tricks here, which are not part of the signed data nor necessary to the verification process of the response, seem to amount to ignoring that relationship, which is why I’m struggling to see how that’s compliant. -- 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 on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHELdjvAYQn8%2BnwrYy2Hc77NsJGLYKJiHCYu8b0RGPG80w%40mail.gmail.com.
