This is indeed the case. While bad faith or malice are very difficult to prove in practice, there are certain scenarios that call the trust in a given Log or Log Operator into question, regardless of date of detection. Such scenarios include but are not limited to:

• Private key compromise of a Log
• Certain non-trivial split-view scenarios
• Egregious or seemingly intentional failure to log certificates or pre-certs for which SCTs exist

From my perspective, there are three sensible states for a Log at the simplest level possible:

1. Currently Qualified
2. Frozen (at a specific STH / date)
3. Disqualified

All Logs would trivially start as Disqualified, wherein no SCTs from these Logs count towards certificate qualification. Applying and being accepted into the trusted Log list brings a Log to the Currently Qualified state. Under normal lifecycle conditions, that is the Log undergoes no incident that results in policy violation, the Log will eventually cease operations and become Frozen. Being Frozen means all SCTs issued before a specific STH / date can count towards certificate qualification, but no SCT after this point will count.

Should a policy-violating incident arise, the result can be a premature Freezing of a Log for issues such as significant uptime violations or a blown MMD. For more severe situations that call into question the integrity of SCTs or the Merkle Tree itself, this Log should no longer be treated as if it has been operated in good faith (Disqualification). It's worth noting that both Disqualification and Freezing depend on client side updates to take up these changes in order to take effect.

While there isn't currently any published guidance on which type of response will be deployed in which scenario, one of the outcomes from the Nov 2017 CT Policy Days was to create better Log Incident Response documentation, which would substantively cover this concern. Look for conversation in the ct-policy group to cover this issue in the near future.