Subject: [TLS] New directions in certificate status

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Oct 2014 21:07:11 -0400

Please note:

http://datatracker.ietf.org/doc/draft-hallambaker-compressedcrlset/
Also note the pending IPR disclosure.

In brief Rob Stradling and myself have come up with a radically new
approach to certificate status that is vastly more efficient than any
previous proposal that provides finer grain certificate status than
the certificate validity interval.

While compressing hash tables might appear to be a fools errand, it
turns out that if the problem is correctly understood, CRLs actually
compress astonishingly well. It is actually possible to represent the
status of every one of the half million revoked certificates in the
WebPKI using fewer bytes than the heavily edited Google CRLSet.

There is still a powerful case for short lived certificates. But the
minimum feasible expiry interval for short lived certs is 48 hours.
Using a compressed CRL in combination with short lived certs would
allow the vulnerability window to be reduced to minutes.

We are of course aware that deployment will require a licensing regime
that meets the need of all parties including competing CAs, open
source software providers, etc. However lacking an existing licensing
regime for the rights holder (if indeed any are granted), I thought it
best to bring this to people's attention first.

The nature of the invention is such that not applying for a patent
would open the possibility that someone else might make a claim as has
happened to me on numerous other occasions. In the past five years
over $50 million has been spent on defending against such patent
claims.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 9 Oct 2014 08:07:02 -0700

> the certificate validity interval.

Good idea. Unfortunately the draft is incomprehensible: key details
are missing. If understand this correctly, the idea is to use a
crit-bit tree to encode the certificate serial numbers, by removing
common prefixes. There are a lot of finicky details to specify, but
this should help.

What would be nice is some hard numbers on how much it helps.

> best to bring this to people's attention first.

Are you saying FRAND or something else?

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Rob Stradling <[email-masked]>
Date: Fri, 10 Oct 2014 15:32:05 +0100

> What would be nice is some hard numbers on how much it helps.

Hi Watson.  I won't comment on the methods right now, but here are some 
hard numbers from my experimental code...

Using a snapshot of Google's Pilot/Aviator CT logs from mid-June, I 
counted 2,616,669 unexpired-and-publicly-trusted certs useable for TLS 
Server Authentication.  I grabbed all of the applicable CRLs that were 
available online and found that 286,875 of these certificates were revoked.

Size of the resulting "Compressed CRLSet": ~182K

That's ~6 bits per unexpired-and-revoked-and-publicly-trusted TLS Server 
Certificate.
Or, to make it sound more impressive, ~0.6 bits per 
unexpired-and-publicly-trusted TLS Server certificate.

<snip>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 10 Oct 2014 15:51:39 +0000

> That's ~6 bits per unexpired-and-revoked-and-publicly-trusted TLS Server

Is this compressed across multiple issuing CAs?  If so who signs
the validity of such a list?  Is the expectation that CRLs will be
vetted and curated by browser vendors (with frequent updates over
a suitably secure channel)?

How does this interact with intramural CRLs maintained by organizations
on their non-public internal networks?  I am guessing this would
be a complementary mechanism.

If this is frequently updated data, would it not be more efficient
to just send the newly expired (CA, serial) pairs when updating,
rather than compressing the whole set.  At which point how important
is the initial compression?

-- 
	Viktor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 10 Oct 2014 12:18:07 -0400

> a suitably secure channel)?

It could be applied either way.

In fact this is part of what we need to discuss going forward because
there is more than one way we could deploy this technology.

One big CRL is one option. Separate CRLs produced by each CA is
another. A third possibility is we join separate CRLs into one large
distribution.

Given that we are already looking at TRANS deployment we might well
want to consider a mechanism that streamlines deployment of both.

> be a complementary mechanism.

I would have to think rather hard about that case. One side effect of
this technology is that the CRL leaks less information than a
traditional one. If all you have is a compressed CRL then you know the
number of revoked certs but you don't know very much about any of
them. A traditional CRL tells you all the serial numbers which might
well leak rather a lot of data.

> is the initial compression?

Delta CRLs have been tried in the past. The problem is that the
relying party still needs to store the serial number of every revoked
certificate. And it gets worse because it is harder to purge the list
for expired certs.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Oct 2014 13:15:41 -0400

The intention is FRAND for application of the compression technique to certificate status.

The way it works is that we take the list of good certs A and the set of bad certs B and we encode only the difference between A and B

Sent from my difference engine

> On Oct 9, 2014, at 11:07 AM, Watson Ladd <[email-masked]> wrote:
>