Confirm, administrator
5,526
edits
Changes
continued drafting text
== Key Compromise ==
Section 6.1.1 of Mozilla's Root Store Policy says that a CSR (certificate signing request) alone does not prove possession of the certificate’s private key for the purpose of initiating a revocation, so the following clarification is made in regards to the keyCompromise revocation reason: <br>
''The scope of revocation depends on whether the certificate subscriber has proven possession of the private key of the certificate. A CSR alone does not prove possession of the certificate’s private key for the purpose of initiating a revocation.''
* ''If anyone requesting revocation has previously demonstrated or can currently demonstrate possession of the private key of the certificate, then the CA MUST revoke all instances of that key across all subscribers.''
* ''If the certificate subscriber requests that the CA revoke the certificate for keyCompromise, and has not previously demonstrated and cannot currently demonstrate possession of the associated private key of that certificate, the CA MAY revoke all certificates associated with that subscriber that contain that public key. The CA MUST NOT assume that it has evidence of private key compromise for the purposes of revoking the certificates of other subscribers, but MAY block issuance of future certificates with that key for that subscriber.''
The reason for this language has been [https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/RVFnJJRuUag/m/9kMbNY-BAwAJ described and discussed in the Mozilla Dev Security Policy forum]. I have copied the explanation of the situation below.
Currently, TLS issuance does not require a demonstration of key control to go from Applicant to Subscriber (e.g. CSR validation is not required). That is because for TLS, we are obtaining evidence that the domain holder '''authorized''' the key, not necessarily that the domain holder '''holds''' the key. There are plenty of debates to be had about this point, but this reflects how the system works today. Therefore, currently the following situation needs to be considered.
# Alice creates a CSR for good.example, using Key 1
# Alice applies at CA Foo with their CSR, becoming an Applicant
# After demonstrating control over good.example, Alice becomes a Subscriber
# Alice stores their CSRs on GitHub
#* The CSR for Alice is by no means a secret, as it is merely a statement of the request.
# Eve obtains a copy of Alice's CSR, and applies to CA Foo for evil.example
# The CA uses their API or Web Form and does not check the attributes from the CSR, so the CSR is not bound to any request
#* The CSR not a proof of possession instrument; it is just a way of conveying an authorized key.
# Eve completes the necessary challenges for evil.example, which ends up authorizing Key 1 to be used with Eve's domain
#* This means Alice could MITM Eve, but in this example Eve is the perpetrator.
# Eve, as Subscriber, requests that CA Foo revoke evil.example{Key 1} for Key Compromise
# CA Foo, on receiving the request, revokes the certificate for evil.example
# CA Foo then examines their systems, and sees that Key 1 is also used by Alice's good.example certificate - and revokes that as well
# Eve has now managed to deny service to Alice, by using the policy for abuse
TO DO
* Have sub section about key compromise regarding CSRs and verifiable evidence of compromise.
