At 5:09 PM +0000 2/4/09, Frank Hecker wrote: >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.)
Whether or not the average CPS/CP has it is irrelevant. Let's look at the standards that all CAs are supposed to be using, in this case RFC 5280: 3.3. Revocation When a certificate is issued, it is expected to be in use for its entire validity period. However, various circumstances may cause a certificate to become invalid prior to the expiration of the validity period. Such circumstances include change of name, change of association between subject and CA (e.g., an employee terminates employment with an organization), and compromise or suspected compromise of the corresponding private key. Under such circumstances, the CA needs to revoke the certificate. "the CA needs to revoke the certificate" seems pretty definitive to me. >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? I do not think there should be an alternative mechanism. At 2:05 AM +0000 2/5/09, Frank Hecker wrote: >* 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. > The CA is not following the PKIX standard: pull their trust anchor. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
