Running a Certificate Transparency log

These sound like good improvements but I still don't really get why the ct log server is responsible for storage at all (as a 3rd party entity)..

Couldn't it just be responsible for its own key and signing incremental advances to a log that all publishers are responsible for storing up to their latest submission to it?

If it needed to restart and some last publisher couldn't give it its latest entries, well they would deserve that rollback to the last publish from a good publisher..

The point of CT logging is to ensure a person can ask "What certificates were issued for example.com?" or "What certificates were issued by Example CA?" and get an answer that's correct - even if the website or CA fucked up or got hacked and certificates are in the hands of people who've tried to cover their tracks.

This requires the logs be held by independent parties, and retained forever.

I understand that. But..

If 12 CAs send to the same log and all have to save up to their latest entry not to be declared incompetent to be CAs, how would all 12 possibly do a worse job of providing that log on demand than a random 3rd party who has no particular investment at risk?

(Every other CA in a log is a 3rd party with respect to any other, but they are one who can actually be told to keep something indefinitely because they would also need to return it for legitimizing their own issuance.)

The publishers can't entirely do the storage themselves since the whole point of CT is that they can't retract anything. If they did their own storage, they could rollback any change. Even if the log forms a verification chain, they could do a rollback shortly after issuing a certificate without arousing too much suspicion.

Maybe there is an acceptable way to shift long-term storage to CAs while using CT verifiers only for short term storage? E.g. they keep track of their last 30 days of signatures for a CA, which can then get cross-verified by other verifiers in that timeframe.

The storage requirements don't seem that bad though and it might not be worth any reduced redundancy and increased complexity for a different storage scheme. E.g. what keeps me from doing this is the >1Gbps and >1 pager requirements.

If CAs have to share CTs and have to save everything the CT would save to their last submission then no CA can destroy the log without colluding with other CAs.

(I.e. your log ends abruptly but polling any other CA that published to the same CT shows there is more including reasons to shut you down.)

I don't see how a scheme where the CT signer has this responsibility makes any sense. If they stop operating because they are sick of it, all the CAs involved have a somewhat suspicious looking CT history on things already issued that has to be explained instead of having always had the responsibility to provide the history up to anything they have signed whether or not some CT goes away.

As far as I know, CAs don't have to "save up to their latest entry"

The info they get back from the CT log may be a Merkle Hash that partly depends on the other entries in the log - but they don't have to store the entire log, just a short checksum.

Right and this is what I am saying is backwards with the protocol. It is not in anyone's best interest that some random 3rd party takes responsibility to preserve data for CAs indefinitely to prove things. The CA should identify where it has its copy in the extension and looking at one CAs copy one would find every other CAs copy of the same CT log.

> Even if the log forms a verification chain, they could do a rollback shortly after issuing a certificate without arousing too much suspicion.

This is not true. A rollback is instantly noticeable (because the consistency of Signed True Heads can not be demonstrated) and is a very large failure of the log. What could happen is that a log issues a Signed Certificate Timestamp that can be used to show browsers that the cert is in the log, but never incorporating said cert in the log. This is less obvious, but doing this maliciously isn't really going to achieve much because all certs have to be logged in at least 2 logs to be accepted by browsers.

> Maybe there is an acceptable way to shift long-term storage to CAs while using CT verifiers only for short term storage? E.g. they keep track of their last 30 days of signatures for a CA, which can then get cross-verified by other verifiers in that timeframe.

An important source of stress in the PKI community is that there are many CAs, and a significant portion of them don't really want the system to be secure. (Their processes are of course perfect, so all this certificate logging is just them being pestered). Browser operators (and other cert users) do want the system to be secure.

An important design goal for CT was that it would require very little extra effort from CAs (and this drove many compromises). Google and other members of the CA/Browser would rather spend their goodwill on things that make the system more secure (ie shorter certificate lifetimes) than on getting CAs to pay for operating costs of CT logs. The cost for google to host a CT log is very little.