Re: [TLS] New directions in certificate status
Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 10 October 2014 15:51 UTC
Return-Path: <ietf-dane@dukhovni.org>
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 6CC6A1A1AED for <tls@ietfa.amsl.com>; Fri, 10 Oct 2014 08:51:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 dnkclaoc3I80 for <tls@ietfa.amsl.com>; Fri, 10 Oct 2014 08:51:41 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811BE1A1A27 for <tls@ietf.org>; Fri, 10 Oct 2014 08:51:41 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B09E62AACFF; Fri, 10 Oct 2014 15:51:39 +0000 (UTC)
Date: Fri, 10 Oct 2014 15:51:39 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20141010155139.GA13254@mournblade.imrryr.org>
References: <CAMm+LwgGmKU+R17zAf8V5XLUfsQ-pn81ujAazZN6K_mtBaxciw@mail.gmail.com> <CACsn0cmf5znHgQquSgxNbAhCzW-7BTMjPhMUj0xe0ZT0p0wENw@mail.gmail.com> <5437EDE5.6020208@comodo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5437EDE5.6020208@comodo.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fPC7ZxyCH3ERvcof2FoTjNnuDUM
Subject: Re: [TLS] New directions in certificate status
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
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 15:51:43 -0000
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)? 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.
- [TLS] New directions in certificate status Phillip Hallam-Baker
- Re: [TLS] New directions in certificate status Watson Ladd
- Re: [TLS] New directions in certificate status Rob Stradling
- Re: [TLS] New directions in certificate status Viktor Dukhovni
- Re: [TLS] New directions in certificate status Phillip Hallam-Baker
- Re: [TLS] New directions in certificate status Phillip Hallam-Baker