On Sun, Jun 28, 2020 at 05:14:47AM -0700, Corey Bonnell via dev-security-policy wrote: > Feedback and suggestions for improvements are greatly appreciated. Even > if this format is not adopted as a standard mechanism for providing proof > of key compromise, I hope that by posting it here there will be robust > discussion on the topic of developing and adopting such a standard > mechanism.
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... Also, in an *extreme* nit-pick, something about the use of the word "proof" in the name doesn't sit right. I refer to the artifacts that I produce as "attestations of compromise", as I feel that's a better description than a "proof". However, it doesn't produce nearly as good an acronym. 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. - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
