On Tue, Jan 17, 2017 at 10:34 AM, Paul Wouters <[email protected]> wrote:
> 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". > Those two goals are not as different as you might think. Either way, you need for the client to detect equivocation. You need the same data; it's just a question of when. > 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. > I think you mean "RPs" where you say "monitors", right? Even in this scenario, in order for the rogue log to be found out, you still need a system for detecting equivocation, which we don't have now. > 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. > As I noted in my little quantitative analysis, you can get the data structures down to a reasonable size with a ~8min issuance delay if you're willing to refactor the log structure. --Richard > > Am I missing something? > > Paul >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
