In the event of a problem with a CA issuing certificates for websites they do not want to, we may want to block all certs issued by that CA from a certain date (e.g. today) forward, but still allow certs issued by that CA before that date to work fine. This error would probably have to be one that the user cannot override in order for this to have the intended effects. Whether the code to implement this belongs in PSM or NSS is an open issue. I suspect that the final changes to support this will split both components, but it is possible to implement this only in PSM.

I wrote this nonsense: "In the event of a problem with a CA issuing certificates - for websites they do not want to, ..." but I meant: In the event that a CA issues certificates for domains for which they should not have issued them and/or when a CA causes a security problem and/or when a CA does not adhere to the policies of our root CA program, ...

Consider the case where a CA is compromised, and the compromise is not known with certainty to be completely closed, and in fact the attacker is capable of successfully performing his attack again. What stops the attacker from back-dating new certs issued thereafter to make them appear to have been issued before the date of compromise? How does this date-based approach help our users in the event that the attacker can back-date new certs from the compromised CA?

Setting an arbitrary start date is likely to be harder in the case where it's an attack against the CA's process/tools rather than their servers: it's not something that's needs to be parameterized as part of the issuing process (though expiry date might be), so it's likely to be harder for an attacker to manipulate. If they can run arbitrary commands on the machine with the private key, it doesn't help, but otherwise I think it's a useful mitigation to have available.

(Does this still need to be confidential?)

Mike's right: if they have enough control to issue arbitrary certs, they can issue certs without CRL or OCSP, and they can issue certs with arbitrary dates - the only way to sort that is to un-trust the root. But in this case, the attacker who pwned the tool could not control either the start date (midnight on the day of issue) or the presence of OCSP or CRL in the cert (I'm sure he would have removed them if he could). So this sort of mitigation would help. I agree this bug no longer needs to be secret, unless we consider it a secret that NSS currently doesn't have this capability :-) Gerv

Were any of the certs generated in this attack CA certs? If so, the attacker has complete control over validity dates in new certs.

No, none were. Gerv

Nelson wrote (in email): > At a minimum, this "deny new [...] certs" approach MUST include CA > certs as well as EE (leaf) certs. This is an important point. In the blacklist we just shipped, we only had to examine the EE cert. For this, we would have to examine every cert in the chain.

(In reply to Nelson Bolyard (seldom reads bugmail) from comment #2) > Consider the case where a CA is compromised, and the compromise is not known > with certainty to be completely closed, and in fact the attacker is capable > of successfully performing his attack again. > > What stops the attacker from back-dating new certs issued thereafter to make > them appear to have been issued before the date of compromise? +1 Also: What do we do when the attacker is the CA itself, trying to work around a suspension of trust? The only thing we have is notBefore. We don't have trustworthy timestamps included in the certificates, especially not from peer (competing) organizations. Since notBefore is set by the attacker, there's no way to do this. We might possibly embed the final CRL, but that relies on the CRL containing issuance data as well as mere revocation data. > How does this date-based approach help our users in the event that the > attacker can back-date new certs from the compromised CA? This proposal cannot be effectively implemented without external timestamps, which cannot be provided without alterations to the Certificate format. I don't believe that it can be done within PSM's current framework.

The next time a CA claims that an attack was against the infrastructure and well contained, we should require that the CA provides proof that it was 100% impossible for the attacker to modify the system time of no single computers involved in creating the certificates. My general worry with this date-based distrust proposal: Can we really trust the statements of an attacked CA that the attack was limited? I believe the major argument for this proposal is "we don't want to break a large percentage of the web". But this well-intentioned goal comes bundled with the risk that the attack might not be as limited as the CA claims. Personally, I would rather like to see evangelism and see the web switching to redundancy (every site owner has a backup certificate from a secondary CA in the drawer), and thereby allowing us to execute the full penalty for CAs that didn't pay the necessary attention to avoid getting hacked - and see this bug WONTFIXed.

Turns out, this actually happened. We ended up implementing a whitelist of certificates allowed to be issued by the CA in question and rejected all others (see bug 1151512 for more details). This solution seemed to work well without a generalized implementation as proposed in this bug, so I don't think this is necessary.

(In reply to David Keeler [:keeler] (use needinfo?) from comment #11) > Turns out, this actually happened. We ended up implementing a whitelist of > certificates allowed to be issued by the CA in question and rejected all > others (see bug 1151512 for more details). This solution seemed to work well > without a generalized implementation as proposed in this bug, so I don't > think this is necessary. What about if a larger CA gets compromised or acts badly, and it is not feasible to create such a whitelist? i.e. the "to big to fail" scenario. I think it would be a good idea to be able to do the date-based approach described in this bug, so we can ensure that there is no CA too big to fail...