[Cryptography] [messaging] Gossip doesn't save Certificate Transparency

Jerry Leichter leichter at lrw.com
Mon Oct 13 15:20:13 EDT 2014

On Oct 13, 2014, at 2:53 PM, Chris Palmer <snackypants at gmail.com> wrote:
>> Yup, and that's been proposed in the past (late 1990s) as a way of getting
>> away from X.509's 1970s origins in offline systems.  Instead of asking a
>> source for a certified copy from some self-appointed authority (certificate
>> from a CA) and then groping around for further information to check whether
>> the certified copy you've just fetched is actually valid (CRL), you just ask
>> the authority directly, "give me the currently-valid, known-good key for X"
>> (pin from Google).  This short-circuits all of PKI.
>> For some reason it hasn't proven too popular with CAs and browser vendors.
> Well, we have static pins in Chrome, Mozilla is starting to do it, and
> HPKP finally made it to Proposed Standards status and is partially
> implemented by Chrome and Firefox now. So I'm not sure why you say
> we're not into it. :)
How many years did it take to get here?

Still, I'm glad we're here.

> We can't ship a giant blob of public keys for all sites, and have that
> be the end of the story, for a variety of raisins.
> * Web sites change even faster than browsers do.
Browsers are already moving to automatic updates.  Updating the list of keys could be done on a faster schedule.

Today's internet isn't yesterday's.

> * We can't even ship a complete list of revoked keys in our CRLSets,
> for size reasons — forget about pins for all sites.
Why?  I did the calculation in my original posting.  You can cover the top 100,000 sites in 30MB.  That's the size of a couple of image files used to make the browser demos look nice.

Plus ... the *changes* to the list are very simple:  Just insertions and deletions, nothing fancy.  So distributing deltas is simple and very cheap.

> * Do site operators really want to let us be the sole managers of
> their cryptographic identities?
As opposed to ... what?  That they rely on the CA's to be the *official* managers, while the browser makers - who after all are the ones with their hands on the code that actually *uses* all those cert's - just stay in the background, with no one needing to examine where they fit in the trust framework?  Besides, if others want to distribute key lists - why not?

> * A big criticism of DNSSEC is that *exacerbates* the trusted third
> party introducer problem: multiply-centralized --> singly centralized.
> This is that.
Multiple-centralized is good if you can trust the aggregate as long as you can trust any single member (ideal case) or the majority (a common case) or really any fraction of the members of the trust set.  But what we have now requires trust *everyone*.  That's *significantly worse* than the single-centralized approach.  (Besides, again, anyone can offer to maintain and distribute a key collection.)

> * Probably other reasons I'm forgetting.
> TTP + CT, TTP + PKP, and TTP + PKP + CT are all pretty darn good. Not
> perfect, but workable.
You really need to look at the details of what they provide to decide if they help at all.  (See the recent long-running thread here complaining that CT doesn't actually help anything.  I've stayed out of that entirely because I'm not sure who's right, so I want to see both sides present their best arguments.)

But the point of my posting was not to attack attempts to improve what we have, but that we should *also* consider "clean sheet" solutions (even if some of them are retreads of ideas form 20+ years ago).

                                                        -- Jerry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20141013/e6b96c90/attachment.bin>

More information about the cryptography mailing list