On 02/04/2009 07:09 PM, Frank Hecker:
1. To what extent do typical CPSs and CPs address this issue? In other
words, if we were to read the average CPS/CP, would it have language
that would unambiguously tell us whether our policy requirement were met
or not? Or is this something that's typically ambiguous and left to CAs'
discretion, or that CAs are prohibited from unilaterally doing under the
terms of their subscriber agreements? (E.g., CA can revoke only at the
subscriber's request.)
Generally CAs can act upon mere knowledge about certain circumstances
for revoking certificates. Because at times, the subscriber is
interested in the misuse of a certificate and hasn't an interest in
requesting revocation. For example Comodo didn't ask me nicely if I'd
like to have the certificate revoked which was wrongfully issued to me.
They just revoked it. Similar CAs can act upon knowing upon key compromise.
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
....and many more points, but the first one is private key compromise.
2. Assuming a CA becomes aware of a compromised key and doesn't revoke
it, what courses of action are open to us other than pulling the CA's
root? Is there serious consideration being given to implementing some
alternative mechanism in NSS or PSM to blacklist certs which we think
are suspect even if the CA does not?
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.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog: https://blog.startcom.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
