Re: [TLS] draft-hallambaker-tlsfeature-02
Nikos Mavrogiannopoulos <nmav@gnutls.org> Wed, 29 May 2013 07:58 UTC
Return-Path: <n.mavrogiannopoulos@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E591121F9133 for <tls@ietfa.amsl.com>; Wed, 29 May 2013 00:58:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvoQMQW+GG-x for <tls@ietfa.amsl.com>; Wed, 29 May 2013 00:58:12 -0700 (PDT)
Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0307321F8756 for <tls@ietf.org>; Wed, 29 May 2013 00:58:11 -0700 (PDT)
Received: by mail-we0-f176.google.com with SMTP id p58so6168553wes.35 for <tls@ietf.org>; Wed, 29 May 2013 00:58:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=PWzD4/ZIdoktGdsExxN+C48XbVMXX8legs/JeI+5BaE=; b=luGZidd99xft/UurXWu6QrK+M40BU778jqKm7AtPYnIzU8ZL73DnE33y+trC9r+V7X 68nXVSUZ9uoWO752xKZMr3AV1v/C72y42rm8G7Kbah/s1zCYVYZOEgyZ2oewiR57/lFz dKiLdHj4oFQo8BXjsGWliNNs37PmI8a2i3q4dINP4a5BYjZCaXWD17jB1Nqa4kmhmylc tYJIKi1h9sGY3NDhW5qmTZ9RUxmstX/hYvzHJbRFeSGDjK1QOLssRbSAgHZEKwS2MQpW nyHm0fzIHBcJ8B3OM65lmuHuCfe4bFyoxC4k5maA4uLRaUHRE0hrK0mY8v4Ar7EPk/MA 1jpw==
X-Received: by 10.194.8.163 with SMTP id s3mr1220015wja.41.1369814291141; Wed, 29 May 2013 00:58:11 -0700 (PDT)
Received: from [10.100.2.17] (94-224-103-174.access.telenet.be. [94.224.103.174]) by mx.google.com with ESMTPSA id eq15sm29362138wic.4.2013.05.29.00.58.09 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 May 2013 00:58:10 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <51A5B50B.8080205@gnutls.org>
Date: Wed, 29 May 2013 09:58:03 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12
MIME-Version: 1.0
To: tls@ietf.org
References: <01af01ce5bc6$67b9b8c0$372d2a40$@digicert.com>
In-Reply-To: <01af01ce5bc6$67b9b8c0$372d2a40$@digicert.com>
X-Enigmail-Version: 1.4.1
OpenPGP: id=96865171
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] draft-hallambaker-tlsfeature-02
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 29 May 2013 07:58:13 -0000
On 05/28/2013 07:11 PM, Ben Wilson wrote: > What if the CA / Browser Forum were to add an optional provision for the > certificate profile of End Entity TLS Certificates that said the following? > > TLS Feature Extension (optional) > > Subscriber Certificates MAY contain the TLS Feature Extension advertising > that the status_request feature of OCSP stapling is available and supported > by the subscriber. If present, this field MUST NOT be marked critical. > See http://tools.ietf.org/html/draft-hallambaker-tlsfeature-02 What is the actual problem the TLS extension on this draft solves? A client doesn't need an extension to drop the connection if an OCSP reply cannot be obtained. Moreover there are very few cases where a server would like to force the client to disconnect if such a reply is not available since the CA's OCSP server is typically outside its control, and which server administrator would like his site to go down every time the CA's server goes down. For the latter if the server is really concerned about the client getting the OCSP replies, he can send them in-band anyway using the status request extension (and if the server doesn't support this extension - as mentioned in the draft - why would it support the new one?) regards, Nikos
- [TLS] draft-hallambaker-tlsfeature-02 Ben Wilson
- Re: [TLS] draft-hallambaker-tlsfeature-02 Nikos Mavrogiannopoulos
- Re: [TLS] draft-hallambaker-tlsfeature-02 Tom Ritter