[TLS] New directions in certificate status

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 09 October 2014 01:07 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1793E1A8840 for <tls@ietfa.amsl.com>; Wed, 8 Oct 2014 18:07:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.123
X-Spam-Level:
X-Spam-Status: No, score=0.123 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8V1tO6jfev1d for <tls@ietfa.amsl.com>; Wed, 8 Oct 2014 18:07:14 -0700 (PDT)
Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5BA51A883F for <tls@ietf.org>; Wed, 8 Oct 2014 18:07:13 -0700 (PDT)
Received: by mail-lb0-f179.google.com with SMTP id l4so207432lbv.10 for <tls@ietf.org>; Wed, 08 Oct 2014 18:07:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=/uRR4IxwH8uVZVnvhnN5AnMVx/96/H1JYzSf+70I4lg=; b=Sf0GJ7yyWaggmFcal5nvNmRSjKx+ryG4O9YnrV2RUz64XI31nWxKjSywDaORC95dsn okxcaypfBZ6d+5BTcLzQ9tvwDfjcKxzsXkJ7dpNYiJ2faBVBok/1bQTvHD5q7EUQQiqO Av6EywQqw3cvhZW61u7Nm/QjaCTueuk3rp1eqNjRzTeC6UNO/n624A30wqrYC2V3A85T rgKV5BYRZZw5A2t4SKd3XD4QMVsfafZaW9hftEpOGjExyL2DQhqkTjbCkkhVgHWc9BpX z6CQ/SbUElDBIyl/uafwzOvV1YPrzkpWvAdE3AL1vqs/ilzujcquFG0nqxLanxPEbvOG 42uw==
MIME-Version: 1.0
X-Received: by 10.152.87.65 with SMTP id v1mr15236543laz.83.1412816831977; Wed, 08 Oct 2014 18:07:11 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.66.196 with HTTP; Wed, 8 Oct 2014 18:07:11 -0700 (PDT)
Date: Wed, 08 Oct 2014 21:07:11 -0400
X-Google-Sender-Auth: t43wIWdTzhYnq7fSocB2y0pF-yw
Message-ID: <CAMm+LwgGmKU+R17zAf8V5XLUfsQ-pn81ujAazZN6K_mtBaxciw@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vxCgoYHjI2bVNYJup7NxpA4I6N8
X-Mailman-Approved-At: Thu, 09 Oct 2014 04:37:54 -0700
Subject: [TLS] New directions in certificate status
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Oct 2014 01:07:16 -0000

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.