On Wed, Aug 12, 2020 at 06:25:00PM -0700, cbon...--- via dev-security-policy wrote: > > I'm yet to have a CA baulk at accepting a CSR as proof of compromise. It > > has the benefit of not having nearly as many superfluous fields as a > > certificate, as well. In terms of being able to deal with the format, I'd > > expect that a CA would be at least as able to deal with validating a CSR as > > a > > certificate, given that their job is to validate CSR signatures, but not > > necessarily to validate certificate signatures... > > The rationale for using a self-signed certificate as opposed to a CSR was > so that the proof/attestation of compromise could not be confused as input > into the certificate request process. Ideally, CA support personnel > wouldn't manually be analyzing the revocation tokens but instead be using > some sort of automated checking (such as the proof of concept I > implemented). Given this, I didn't feel the overhead of specifying and > verifying additional fields in the certificates as opposed to the simpler > structure of the CSR would be an issue if automation were in place.
I think we're a *long* way away from being able to assume pervasive automation. So far as I can determine, we've got one CA that's possibly automating processing CSRs, and one CA that's using automation to try and get around the need to investigate key compromises. Beyond that... crickets. > > The "standardised" key compromise attestation format I've been leaning > > towards is a CSR whose subject DN is something like "CN=This key is > > compromised!", and which includes a critical "poison" extension, to minimise > > the risks of accidental acceptance still further. I'm still unsure about > > how to control for the possibility of social engineered mis-signing, because > > the idea of someone managing to pull such a trick concerns me, but there's > > an argument to be made that if someone can be tricked into signing arbitrary > > content, that key is kinda busted anyway. > > I don't believe the critical poison extension will help much to prevent > the CSR from being used as input for a lot of CAs, as the typical CSR > input process only consumes the public key and perhaps a list of > SANs/subject CN. For example, it appears that Boulder doesn't look at the > criticality bit of requested extensions at all when parsing a CSR [1]. Yeah, CSR processing is disturbingly hit-and-miss. My thinking with adding the extension is to make it as unambiguous as possible that this is CSR is weird and special and not for ordinary use. Beyond that... At any rate, I'm yet to come up with a *new* attack that a standardised CSR-based attestation of compromise creates. I've got: * Use a key-compromise attestation to get a certificate for a compromised key: the key's compromised, if you *really* want to use that key, you can probably use the actual key, and CAs shouldn't be issuing certs for compromised keys. * Find a "real" CSR and trick the CA into using that as "proof" of compromise: that's at least as likely to happen now, since CAs already accept CSRs as proof of compromise. To the extent that CAs are automating CSR processing for key compromise already, a standardised format can only help, because there's fewer corner cases they'd have to worry about catching in their automation. > Nonetheless, it sounds like we're both in agreement that the ideal format > is a standard container as opposed to something bespoke. Yes, my early experiments with using something that was unambigously unrelated to the X.509 ecosystem did not go well. As an aside, I've got a first draft of my own key compromise attestation format at https://github.com/pwnedkeys/key-compromise-attestation-rfc; I'm probably going to ask LAMPS if they want to recharter to take it on, otherwise I'll just run it through as an independent experimental submission. Commentary gratefully received (probably best as GitHub PRs/issues). - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
