As a summary of the situation, we consider that:
a) Affected certificates do not comply with the norm (EKU OCSPSigning
without OCSP-no-check extension). They are misissued and they must be
revoked
b) This non-compliance issue has potential security risks in case of key
compromise and/or malicious use of the keys, as indicated by Ryan Sleevi.
c) No key has been compromised nor has the malicious or incorrect use of
the key been detected, so at the moment there are no security incidents
d) There are two groups of affected CAs: (i) CAs that maintain sole
control of the affected keys and (ii) CAs that have delegated the
control of these keys to other entities.
e) In the case of CAs who DO NOT have sole control of the affected keys:
in addition to revoking the affected certificates, they should request
the delegated entities to proceed with the destruction of the keys in a
safe and audited manner. This does not guarantee 100% that all copies of
the keys will indeed be destroyed, as audits and procedures have their
limitations. But it does guarantee that the CA has done everything in
their power to avoid the compromise of these keys.
f) For CAs that DO have sole control of the keys: There is no reason to
doubt the CA's ability to continue to maintain the security of these
keys, so the CA could reuse the keys by reissuing the certificate with
the same keys. If there are doubts about the ability of a CA to protect
its own critical keys, that CA cannot be considered "trusted" in any way.
g) On the other hand, if the affected certificate (with EKU OCSPSigning)
does not have the KU Digital Signature, then that certificate cannot
generate valid OCSP responses according to the standard. This situation
has two consequences: (i) the CA cannot generate OCSP responses by
mistake using this certificate, since its own software prevents it, and
(ii) in the event that an attacker compromises the keys and uses
modified software to generate malicious OCSP responses, it will be also
necessary that the client software had a bug that validated these
malicious and malformed OCSP responses. In this case, the hypothetical
scenarios involving security risks are even more limited.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
