Are CT logs expected to keep entries forever?

[Santhan Raj]

I have a novice question. Is a CT log expected to keep growing forever? As far as I can tell, there doesn't seem to be any provision to remove entries from the log. Is the expectation that a log will continue to grow forever and will hold all entries forever? Or will each at some point stop accepting new entries and will eventually be decommissioned once all entries (certs) in the log expires? 

Thanks,

Santhan

[Eran Messeri]

Hi,

Indeed there's no provision for removing entries from the log (and the ones under discussion are for removing individual entries, not entire sub-trees).

The expectation is that logs that are not backed by a scalable implementation will be frozen at some point and replaced with newer ones. Furthermore, it's easy to mirror logs, so frozen logs can be served from a cheaper infrastructure than the one used for running live logs.

Eran

--
You received this message because you are subscribed to the Google Groups "certificate-transparency" group.
To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transparency+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Santhan Raj]

Thanks Eran, appreciate the response. You said "frozen" instead of "decommission". Can/Should a CT log be ever decommissioned? If yes, when? Is it after every cert in the log expires?

Thanks,

Santhan

[Eran Messeri]

It depends on the relationship to the log:

* TLS clients care about the log's integrity, so they can still consider SCTs issued by an inactive logs as valid (as if the log was still active). That is only true if they can audit the log (even via a mirror of the log). When all certificates in a log expire, it is of no further use to TLS clients.

* The log operator cares about operating costs, so the operator could serve a read-only copy or even fully decommission a log, if it is mirrored elsewhere. It is the operator's choice.

* Monitors (more generally, entities interested in inspecting certs) can mirror the log and may want to hold onto the entries of a log even after it has been fully decommissioned.

The answer to your question depends on who's asking the question - if you can clarify the motivation behind your question, we can further discuss implications of log growth / freezing / decommissioning from that aspect.

Eran

[Santhan Raj]

Thanks for the details. I was interested in what log decommission means from a TLS client perspective, and you answered it!

Thanks,

Santhan

[Eran Messeri]

From a TLS client perspective, a log could be in 3 states:

1. Recognized / trusted: All SCTs from that log are accepted.
2. Frozen: SCTs up to a certain point in time are accepted.
3. Unknown / distrusted: No SCTs from that log are accepted.

In both states (1) and (2) TLS clients must audit the log in the same way, to ensure the log is operating correctly and each issued SCT corresponds to an entry in the log's Merkle tree (particularly in the 2nd case - to detect back-dating of SCTs). 

Auditing the log can be done against the log itself or against   a mirror operated by a third-party. It is already the case in Chrome that SCTs from logs that have been effectively decommissioned are still accepted.

Distrusting a log, once misbehaviour was detected, is more nuanced: A naive approach could be white-listing all log entries that are publicly known (for example, are in a mirror) and removing the log's key from the TLS client - so existing certificates+SCTs from that log are still valid (and CT-compliant), but the log's key cannot be misused.

Eran 

Santhan

To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transparency+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.