Timeline for Why should my certificate signing request be signed by my private key?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 7, 2021 at 8:14 | history | edited | CommunityBot |
replaced https://tools.ietf.org/html/rfc with https://www.rfc-editor.org/rfc/rfc
|
|
| Sep 11, 2017 at 23:53 | comment | added | Jonathan Gray | I apologize for the late reply but I would like to point out that CAs are solely responsible for ensuring the legitimacy of the information provided in the CSR and for verifying ownership. Ownership of the associated private key is the only thing in a CSR that a CA cannot independently verify. Therefore logically the attack should only be feasible as described in RFC2986. | |
| Dec 27, 2015 at 19:03 | vote | accept | STEMExchanger | ||
| Dec 27, 2015 at 13:33 | comment | added | Gilles 'SO- stop being evil' |
@StackzOfZtuff No, the thing in RFC2986 is about having the CA validate the association between Eve's public key and acme.com without proof. It's related, of course, but the scenarios where this would come into play are a bit different — normally, when you rely on the association between the DN and the public key, you'd require a proof of possession of the private key, and RFC2986 warns against protocols that don't do this properly. For the association between DN and CN, there's no way to apply extra crypto, so if you rely on that (which is unusual), the CA is the only defense.
|
|
| Dec 27, 2015 at 13:19 | comment | added | StackzOfZtuff | Okay. I get that. But isn't that exactly what RFC2986 warns about? | |
| Dec 27, 2015 at 11:23 | history | answered | Gilles 'SO- stop being evil' | CC BY-SA 3.0 |