On Tue, 10 Mar 2020 at 22:19, Ryan Sleevi <r...@sleevi.com> wrote: > > > On Tue, Mar 10, 2020 at 4:25 PM bif via dev-security-policy < > dev-security-policy@lists.mozilla.org> 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. >
Most likely :) Take it as more general musings for having generally accepted recipes for providing proof of key possession, using which would not allow CAs to wiggle out of responsibility of revocation. > 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. > Sure, as long as CN is long enough, and CSR is clean, ie. no extensions allowing to fit, say, collision attacks. > > 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. > As a CA I would most likely accept this proof, considering the incredibly low false positive possibility. :) All I'm saying is that proof of key possession is not clearly defined in the absence of said key being shared with a CA. > > >> 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. > I am totally against putting unreasonable onus on reporters! But hopefully you agree that CAs should strive for zero false positives in revocations. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
