We should reposition the debate again, because a false reality is being
assumed.
Some people are assuming that this is the real situation: "A security
incident has occurred due to the negligence of certain CAs, and this
security incident has got worse by the CAs' refusal to apply the correct
measures to resolve the incident, putting the entire community at risk".
But this description of the situation is not true at all, for many
reasons and on many levels.
By order:
a) There is no security incident. Since no key has been compromised and
there is no suspicion that a key compromise has occurred.
b) There has been no negligence, errors, or suspicious or malicious
behavior by any CA in the issuance of these certificates. All affected
certificates have been issued following good practices and trying to
comply with all the applicable security standards and regulations.
c) The only relevant event that occurred recently (July 1) is that a
person, acting unilaterally and by surprise, reported 14 incidents in
the Mozilla Root Program about 157 ICA certificates misissued
(certificates issued with the EKU "OCSPSigning" without the extension
"OCSP-nocheck"). The wording of the incidents assumes that "his
interpretation of the standards is the correct one" and that "his
proposed solution is the only valid one".
d) This is not a new incident since most of the certificates affected
were issued years ago. The existence of this ambiguity in the standards
was made public 1 year ago, on September 4, 2019, but the debate was
closed without conclusion 6 days later
(https://groups.google.com/g/mozilla.dev.security.policy/c/XQd3rNF4yOo/m/bXYjt1mZAwAJ).
e) The reason why these 157 ICA certificates were issued with EKU
"OCSPSigning" was because at least 14 CAs understood that it was a
requirement of the standard. They interpreted that they must include
this EKU to simultaneously implement three requirements: "CA Technical
Restriction", "OCSP Delegate Responders" and "EKU Chaining".
Unfortunately, on this point the standard is ambiguous and poorly written.
f) Last year, a precedent was created with the management of the
"Insufficient Serial Number Entropy" incident. Many CAs were forced to
do a massive certificate revocation order to comply with the standards
"literally", even if these standards are poorly written or do not
reflect the real intention of the editors.
g) None of the 157 ICA certificates affected were generated with the
intention of being used as "Delegated OCSP Responders". None of the 157
certificates has been used at any time to sign OCSP responses.
Additionally, most of them do not include the KU Digital Signature, so
according to the standard, the OCSP responses that could be generated
would not be valid.
h) As a consequence of these discussions, a Security Bug has been
detected that affects multiple implementations of PKI clients (a CVE
code should be assigned). The security bug occurs when a client PKI
application accept digitally signed OCSP responses for a certificate
that does not have the "DigitalSignature" KeyUsage active, as required
by the standard.
i) There is no procedure in any standard within Mozilla Policy that
specifies anything about "key destruction" or "reuse of uncompromised keys".
j) As long as the CAs maintain sole control of the affected keys, there
is no security problem. For a real security incident to exist, it should
happen simultaneously: (i) the keys were compromised, (ii) they were
used to generate malicious OCSP responses, (iii) some client application
accepted these OCSP responses as valid and (iv) the revocation process
of the affected certificate was ineffective because the attacker was
able to generate fraudulent OCSP responses about its own status. Still,
in that case there is a quick and easy solution: remove the affected CA
Root from the list of trusted CAs.
k) The real risk of this situation is assumed by the affected CAs and
not by the end users, since in the worst case, the ICA key compromise
would imply the revocation of the CA Root.
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
