Re: [TLS] New directions in certificate status

Phillip Hallam-Baker <ietf@hallambaker.com> Fri, 10 October 2014 16:22 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 238411A87CD for <tls@ietfa.amsl.com>; Fri, 10 Oct 2014 09:22:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 qA45uzAug0-I for <tls@ietfa.amsl.com>; Fri, 10 Oct 2014 09:22:31 -0700 (PDT)
Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30BDB1A8ABA for <tls@ietf.org>; Fri, 10 Oct 2014 09:18:12 -0700 (PDT)
Received: by mail-lb0-f177.google.com with SMTP id w7so3419971lbi.36 for <tls@ietf.org>; Fri, 10 Oct 2014 09:18:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=/CsEYXpN/WteHGT0Ng4xrIrZZ3MxbmXDzCl8LFkCikk=; b=LgNz3X7abCky0KADAVJjdHngyQPgldzAis/6gqdFsLkI6olOUM2QCix7OMIppMA+hA UKqnxRSKO2IF1rYOyoc5cw7ACVRUPf6AHqqym9fH4Z7POjltu0+hoB35Qw516d56iASm UFceJukIU1FVM7dv9tkvxhDFva1YocrMA8vGs+6Ujjad9yGT40PRp9P+Yu9Fsl5uLoGm eNuuu758Vx0+hHNuDZL+CHle1fRAf8ODbMcwWuSDPg1m7qicPTFRNwskXAKpddQqzeWE 5c4WQWS8p/9Us6/Y3TtZRt7dp7/FACqpIyK3lnrmHGihpVdB9lryqbIDY5K6ByY0CHZk fWqw==
MIME-Version: 1.0
X-Received: by 10.112.204.197 with SMTP id la5mr5878691lbc.2.1412957887929; Fri, 10 Oct 2014 09:18:07 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.66.196 with HTTP; Fri, 10 Oct 2014 09:18:07 -0700 (PDT)
In-Reply-To: <20141010155139.GA13254@mournblade.imrryr.org>
References: <CAMm+LwgGmKU+R17zAf8V5XLUfsQ-pn81ujAazZN6K_mtBaxciw@mail.gmail.com> <CACsn0cmf5znHgQquSgxNbAhCzW-7BTMjPhMUj0xe0ZT0p0wENw@mail.gmail.com> <5437EDE5.6020208@comodo.com> <20141010155139.GA13254@mournblade.imrryr.org>
Date: Fri, 10 Oct 2014 12:18:07 -0400
X-Google-Sender-Auth: FomqNM2m7PMczAI1EHt33tvYqBU
Message-ID: <CAMm+LwgtZ4cRDw=pdtrT=Xu4T7xVS4qvjd8-1WEgOzdMAbUOfg@mail.gmail.com>
From: Phillip Hallam-Baker <ietf@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/XW-8DdkE-UlA_n2br8SF9-weISA
Subject: Re: [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: Fri, 10 Oct 2014 16:22:33 -0000

On Fri, Oct 10, 2014 at 11:51 AM, Viktor Dukhovni
<ietf-dane@dukhovni.org> wrote:
> On Fri, Oct 10, 2014 at 03:32:05PM +0100, Rob Stradling wrote:
>
>> Size of the resulting "Compressed CRLSet": ~182K
>>
>> That's ~6 bits per unexpired-and-revoked-and-publicly-trusted TLS Server
>> Certificate.
>
> 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)?

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.


> 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.

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.


> 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?

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.