Eddy Nigg wrote re revocation on compromise:
Generally CAs can act upon mere knowledge about certain circumstances
for revoking certificates.
<snip>
I believe that the StartCom CPS isn't unique in regards to revocation
which states:
Circumstances for Revocation
Revocation of a certificate is to permanently end the operational period
of the certificate prior to reaching the end of its stated validity
period. A certificate will be revoked when the information it contains
is suspected to be incorrect or compromised. This includes situations
where:
● The subscriber’s private key is lost or suspected to be compromised
Thanks for your info as well.
Mozilla (Gerv, Nelson, me, others) evaluated the option to ship such a
blacklist but the idea was rejected to be unpractical (the blacklist
download would have been larger than that of Firefox itself). Don't know
of any other action Mozilla could perform besides what you mentioned
already.
Understood. After thinking about this, here is what I think we should do
on this issue:
* In the near term I think we should make it a recommended practice that
CAs should revoke certificates whose private keys are known to be
compromised, as well as certificates for which subscriber verification
is known to be invalid. Kathleen can then add a check to determine
whether a CA's CPS has language that is consistent with our
recommendation, and we can discuss that as part of overall evaluation of
CAs.
I've add an item for this to the "recommended practices" page:
https://wiki.mozilla.org/CA:Recommended_Practices
Feel free to suggest tweaks to the language as appropriate.
* In the longer term we can consider making this a policy requirement.
There are likely some ambiguities and corner cases we need to worry
about, which is one reason why I'd like us to first get some experience
with what CAs are actually putting in their CPSs.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
