On Mon, 16 Jan 2017, Richard Barnes wrote: Speaking as individual only...
- It is not practical to build a publicly verifiable log system that incorporates SCTs - The existing tools for public verifiability need to be made more efficient in order to work on the scale envisioned
So I think there might be a different perception here of the goal of CT. I think you are looking at a 100% catch-before-it-happens scenario. While the document is only about "exposing rogue parties".
Fundamentally, CT is a public ledger system: every certificate is supposed to be entered into a log and RPs only accept certificates which are logged. In order for this to work properly, RPs need to be able to verify that there is public consensus about the state of the log. Otherwise, logs can “equivocate”: represent to the RP that a given certificate was published when it in fact was not. Unfortunately, in practice RPs are not doing this verification (for reasons discussed below), and so CT reduces to a countersignature scheme in which the RP trusts the log not to equivocate. There are two primary challenges here, as detailed below.
The monitors are supposed to use multiple logs, presumably not all of which are colluding. So a rogue log would be found out and lose its trust? Maybe not in time for this one client visiting this one website, but that was never the expected goal of CT.
It has been known for quite some time that the public verifiability piece of CT introduces latency in certificate issuance. In order to allow for immediate certificate issuance, logs instead issue SCTs, which are just promises to incorporate the certificate into the log; effectively the SCT is a countersignature on the certificate. However, if an RP accepts a certificate + SCT, then it is vulnerable to collusion between a CA which issues a bogus cert and a log which issues a bogus SCT but never incorporates the cert into the log.
So that is someting monitors should look at.
We are unaware of any way to efficiently address this issue without introducing either privacy problems or latency. In order to validate inclusion in the log, the RP needs to validate that other entities (e.g., the software manufacturer) have the same view of the log. Either the RP downloads the whole log (which is inefficient), queries for the specific certificate in question (which has privacy problems) or retrieves a checkpoint which vouches for some batch of certificates (which introduces batch latency).
So personally, I would like to know that ACME-style issued certificates would start being accepted within a few minutes. At least for those sites that did not have a certificate before. If we are talking about renewing, then it should be able to properly submit new entries to log before actually activating the new certs, so some latency wouldn't matter. Am I missing something? Paul _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
