It is always a mistake to imagine that political outcomes are the product of rational analysis rather than the respective power relationships and constraints.
For Google, the risk of consequences due to CA breach are arguably higher than the consequences of end-entity breach which they have controlled through shifting liability onto the CAs. But for the typical Internet user, the risk due to end-entity breach is higher. I didn't say we shouldn't do CT, what I said is that we have to make revocation an equal priority. Checkpointing revocation information in CT makes great sense for all concerned. Had Harber-Stornetta catenate certificates been available on equitable terms prior to the expiry of the patent we would probably have done something like CT years ago. The reason we didn't do revocation before was that we did not develop a technology that the browser providers considered acceptable. And then we spend ten years trying to persuade them that up was down rather than fixing the problem. Not trying to assign blame here, I should have arrived at this analysis ten years ago. On Mon, Nov 17, 2014 at 12:07 PM, Trevor Freeman <trevor.freema...@icloud.com> wrote: > Obviously more that you think otherwise folks would not be working on CTJ > > > > -----Original Message----- > From: therightkey [mailto:therightkey-boun...@ietf.org] On Behalf Of Phillip > Hallam-Baker > Sent: Sunday, November 16, 2014 12:30 PM > To: Trevor Freeman > Cc: Massimiliano Pala; therightkey@ietf.org > Subject: Re: [therightkey] [pkix] Proposal for working on PKIX revocation > open issues > > > > On Sun, Nov 16, 2014 at 1:53 PM, Trevor Freeman > <trevor.freema...@icloud.com> wrote: > >> Hi Max, > >> > >> I think we first need a consensus of the unmitigated threats this work > >> would look to address. That would help assess the technical options. > >> Top of my list of unmitigated threats would be compromised CA issuing > >> user certificates outside of the normal process e.g. attackers use > >> some tool to sign the certificate direly using the CA key so no log > >> exists of the issuance. > > > > Seriously? > > > > How often does this happen? > > > > How often does an administrator sell a machine without zeroing the hard > drive where a live key is stored? How often does a corrupt admin sell a > private key? How often does a machine without a TPM with a cert get rooted? > > > > > > End entity breach is a daily occurrence. > > > >> For example, if there is consensus on that as a threat to be > >> addressed, OCSP does not help much in that you want a "known to be > >> good" assertion, not a "know to be bad" assertion that revocation > >> checking provides. Certificate reissuance has been long been cited as > >> an alternative to revocation in that you get a restatement of the > >> goodness which is what you need, but it does tax the CAs. If you are > >> targeting server validation scenarios, then a Valid Certificate List > >> which was similar to CRLs but a list of good certificates could scale > >> much better as Phil points out. Given we know all too well what does not >> work well with CRLs, we should be able to avoid the mistakes i.e. > >> use hashs to identify certificates not issue\serial number, mandate > >> support for partitions etc., etc. > > > > I much prefer using hash based mechanisms to issuer/serial. But in a pinch, > I will use hash of the issuer/serial :) > > > > _______________________________________________ > > therightkey mailing list > > therightkey@ietf.org > > https://www.ietf.org/mailman/listinfo/therightkey _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
