Re: [TLS] OCSP must staple

Viktor Dukhovni <viktor1dane@dukhovni.org> Sat, 07 June 2014 18:47 UTC

Return-Path: <viktor1dane@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 A9D051A01BF for <tls@ietfa.amsl.com>; Sat, 7 Jun 2014 11:47:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 6xxGIxt4XkRI for <tls@ietfa.amsl.com>; Sat, 7 Jun 2014 11:47:46 -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 5D0A31A01BD for <tls@ietf.org>; Sat, 7 Jun 2014 11:47:46 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C6E852AB221; Sat, 7 Jun 2014 18:47:37 +0000 (UTC)
Date: Sat, 7 Jun 2014 18:47:37 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20140607184737.GD27883@mournblade.imrryr.org>
References: <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <CAMm+LwgTnva9jJgVfkaOZ1qP0Rk3w-mFfepnubosgtrCEARv=g@mail.gmail.com> <539069CC.5010304@cs.tcd.ie> <CAFewVt4p4rJ738Yo=XQm6T_jyvG3TnJsSQ5HDZDrqAkyNDa7tg@mail.gmail.com> <20140605173223.GK27883@mournblade.imrryr.org> <20140607164945.GA23329@roeckx.be> <20140607170619.GC27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7A@USMBX1.msg.corp.akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7A@USMBX1.msg.corp.akamai.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sdl24kdWCsKaVMJRxGXC_lTxI8Q
Subject: Re: [TLS] OCSP must staple
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: Sat, 07 Jun 2014 18:47:47 -0000

On Sat, Jun 07, 2014 at 02:13:24PM -0400, Salz, Rich wrote:

> > If CAs start issuing "must staple" certificates, isn't that "forced"?
> 
> In theory, but not in reality.  What is the enforcement mechanism?
> Trust is, ultimately, a relying party issue.  Commerce and financial
> sites would like to do OCSP stapling, but they won't require it if
> it means their customers cannot connect.  Er, trust me on this one. :)

Well, if the server *is* OCSP stapling capable, there is little
harm in having a "must staple" certificate.  So those servers won't
object to having such a certificate.  That leaves servers that can't
OCSP staple, and I guess you're sayign CAs will continue to provide
certicates without the extension to anyone who wants it.

So this another working revocation for the select few mechanism. :-)

So be it, no harm done, but larger problem lies upstream, working
revocation for the masses.

-- 
	Viktor.