There are two states in the NIST key state transition diagram that are appropriate to this entire concept... "compromised" (state entered when the private information associated with it -- i.e., the private key and its passphrase, and has only one possible state transition from it) and "compromised destroyed" (state entered either from "compromised", when no information is protected with that key anymore, or from "destroyed", when no information is protected with that key and it is later found to have been compromised during its non-destroyed period).
Once a key is in compromised state, it can never become uncompromised again. Enforcing this is part of the trust that I have in the certification authorities -- and why I don't currently trust any of them to tell me who anyone happens to be, since any CPS which states that certificate revocation can only be done at the request of the subscriber inherently cannot allow the CA to do its job. -Kyle H On Wed, Feb 4, 2009 at 6:05 PM, Frank Hecker <hec...@mozillafoundation.org> wrote: > 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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
