<p>Interesting model having a firm sponsor a specific part of the infrastructure. Don't think I've seen this before, reminds me of sports style sponsorships.<p>Great that lets encrypt gets funding, long may it continue!
<p>The existing CT logs are (almost all) each run by individual companies.<p><a href="https://crt.sh/monitored-logs" rel="nofollow">https://crt.sh/monitored-logs</a><p>But this might be the first time that a company has sponsored a CT log without operating that log itself.
<p>Awesome! I love CT logs and use a service called Cert Spotter  to notify me every time a new cert is generated for one of my domains. This knocks out their Q1 goal , I'm very excited about their Q2 goal of Multi-Perspective Validation . It will make getting a cert issued to a malicious actor via BGP hijacking much more difficult. I'm also excited about them getting a ECDSA root certificate and was bummed out when it de-prioritized from being a 2018 feature, but Multi-Perspective Validation is certainly a better priority. All this provided for free, lets encrypt is certainly one of my favorite non-profits .<p> <a href="https://sslmate.com/certspotter/" rel="nofollow">https://sslmate.com/certspotter/</a><p> <a href="https://letsencrypt.org/upcoming-features/" rel="nofollow">https://letsencrypt.org/upcoming-features/</a><p> <a href="https://letsencrypt.org/2018/12/31/looking-forward-to-2019.html" rel="nofollow">https://letsencrypt.org/2018/12/31/looking-forward-to-2019.h...</a><p> <a href="https://letsencrypt.org/donate/" rel="nofollow">https://letsencrypt.org/donate/</a>
<p>> <i>Great use case for blockchain technology</i><p>>> <i>CT logs are already chained</i><p>Trillian is a centralized Merkle tree: it doesn't support native replication (AFAIU?) and there is a still a password that can delete or recreate the chain (though we can track for any such <i>inappropriate</i> or errant modifications (due to e.g. solar flares) by manually replicating and verifying every entry in the chain, or <i>trusting</i> that everything before whatever we consider to be a known hash (that could be colliding) is unmodified (since the last time we never verified those entries)).<p>According to the trillian README, trillian depends upon MySQL/MariaDB and thus <i>internal/private</i> replication is as good as the SQL replication model (which doesn't have a distributed consensus algorithm like e.g. paxos).<p>A Merkle tree alone is not a blockchain; though it provides more assurance of data integrity than a regular tree, verifying that the whole chain of hashes actually is good and distributed replication without configuring e.g. SSL certs are primary features of blockchains.
<p>Which components of the system are we discussing?<p>PKI is necessarily centralized: certs depend upon CA certs which can depend upon CA certs. If any CA is compromised (e.g. by theft or brute force (which is inestimably infeasible given current ASIC resources' preference for legit income)) that CA can sign any CRL. A CT log and a CT log verifier can help us discover that a redundant and so possibly unauthorized cert has been issued for a given domain listed in an x.509 cert CN/SAN.<p>The CT log itself - trillian, for Google and now LetsEncrypt, too - though, runs on MySQL; which has one root password.<p>The system of multiple independent, redundant CT logs is built upon databases that depend upon presumably manually configured replication keys.<p>Does my browser call a remote log verifier API over (hopefully pinned with a better fingerprint than MD5) HTTPS?
<p>There are multiple issuers, so from an availability point of view, if one is down, you could choose another. They submit to at least two logs, so if one log is unavailable you could read the other one. This is a form of decentralization.<p>Now, from a security point of view, it only takes breaking into one issuer to issue bad certificates. But maybe classifying everything as either centralized or decentralized is too simple?
<p>Centralized and decentralized are overloaded terms. We could argue that every system that depends upon DNS is a centralized (and thus has a single point of failure).<p>We could describe replication models as centralized or decentralized. Master/master SQL replication is still not decentralized (regardless of whether there are multiple A records or multiple static IPs configured in the client).<p>With PKI, we choose the convenience of trusting a CA bundle over having to manually check every cert fingerprint.<p>Whether a particular chain is centralized or decentralized is often bandied about. When there are a few mining pools that effectively choose which changes are accepted, that's not decentralized either.<p>That there are multiple redundant independent CT logs is a good thing.<p>How do I, as a concerned user, securely download (and securely mirror?) one or all of the CT logs and verify that none of the record hashes don't depend upon the previous hash? If the browser relies upon a centralized API for checking hash fingerprints, how is that decentralized?
<p>Looks like there is a bit here about how to get started:
<a href="https://security.stackexchange.com/questions/167366/how-can-i-access-the-certificate-transparency-logs" rel="nofollow">https://security.stackexchange.com/questions/167366/how-can-...</a><p>Most people aren't going to do it, but I think that's not really the point, any more than every user needs to review Linux kernel patches. But I wonder if there are enough "eyes" on this and how would we check?
<p>I'd say it's more of a tree than a chain, but yes. <a href="https://www.certificate-transparency.org/log-proofs-work" rel="nofollow">https://www.certificate-transparency.org/log-proofs-work</a>