On Tue, Mar 10, 2020 at 4:25 PM bif via dev-security-policy < [email protected]> wrote:
> Matt, > > Voluntarily providing CSR is not an ideal way to prove key compromise, > because you could've simply found this CSR somewhere (I know, I know, super > unlikely with your Subject... but still could happen.) > That seems to be making the perfect the enemy of the good. This seems like a perfectly reasonable thing to allow and accept. If we're concerned about someone "might" having done something as a reason to reject it, it seems like we'd need another pass through the BRs validation methods - e.g. to remove the non-IANA-reserved mail addresses. I don't disagree that this is a possibility, but the probability of this possibility seems incredibly low, and the risk of a CA deciding to revoke on this basis seems immeasurably better than the risk of deciding to not revoke. > And while "compromised" is way too short (one can sign up to 32 bytes > using it as a nonce in regular TLS session) to prove the key compromise, in > the absence of the actual compromised private key, about the only way to > ensure the possession is to get the reporter to sign some data chosen by > the CA. It very well may be a random CN in the CSR, or plain old openssl > dgst. > I'm concerned about CAs disproportionately adding burdens to reporters of compromise. For example, your 'compromised' case doesn't really make sense. The string 'compromised', or even the hash of the string 'compromised', would not in and of itself be a sufficient TLS transcript. I agree with you that one can't simply /look/ for the string 'compromised' in the unsigned data, where that signed data is a TLS transcript, but that's not what you really described, and that distinction seems important. I also disgree with, and have concerns with, the CA being able to direct the signing of the data. I think the ecosystem learned a lot from the Heartbleed scenario, of "We're not affected, we're not affected... oh crap, we're affected". I'm sympathetic to CAs wanting to filter out the noise of shoddy reports and shenanigans, but I'm also highly suspicious of CAs that put too unreasonable an onus on reporters. It seems, in the key compromise case, the benefit of the doubt should largely deal with the reporter. If we saw some quantifiable increase in hijinks and misrevocations, there are a myriad of ways to deal with that. The most effective of these reasons seems to be facilitating rapid replacement of certificates, rather than preferring ossification. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
