IETF Logo Mail Archive

Re: [TLS] Status of X.509v3 TLS Feature Extension?

"Salz, Rich" <rsalz@akamai.com> Mon, 28 April 2014 16:04 UTC

Return-Path: <rsalz@akamai.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 91AD81A6F11 for <tls@ietfa.amsl.com>; Mon, 28 Apr 2014 09:04:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] 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 PCVd39pOQEI4 for <tls@ietfa.amsl.com>; Mon, 28 Apr 2014 09:04:21 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 764A41A6F07 for <tls@ietf.org>; Mon, 28 Apr 2014 09:04:21 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9D7A5474D0 for <tls@ietf.org>; Mon, 28 Apr 2014 16:04:20 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 915CA474B8 for <tls@ietf.org>; Mon, 28 Apr 2014 16:04:20 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 8CF2C2026 for <tls@ietf.org>; Mon, 28 Apr 2014 16:04:20 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Mon, 28 Apr 2014 12:04:20 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: "tls@ietf.org" <tls@ietf.org>
Date: Mon, 28 Apr 2014 12:04:19 -0400
Thread-Topic: [TLS] Status of X.509v3 TLS Feature Extension?
Thread-Index: Ac9i+TbsVyE+DindR+6uBpIWtf1M6AAACdgg
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F669@USMBX1.msg.corp.akamai.com>
References: <CA+aixj_i8XF2buDNMOp2=_Z0XzT3R4uGfxJtjoGt-_PButSggw@mail.gmail.com> <CA+cU71=FtZfzGktLhLz_j99mQ=LVbd0kzz0ZyGbewQUS0ouEGA@mail.gmail.com> <535E353A.9030008@comodo.com> <20140428142029.GT27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F59F@USMBX1.msg.corp.akamai.com> <20140428145250.GU27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F5D0@USMBX1.msg.corp.akamai.com> <20140428151053.GV27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F625@USMBX1.msg.corp.akamai.com> <20140428154742.GW27883@mournblade.imrryr.org>
In-Reply-To: <20140428154742.GW27883@mournblade.imrryr.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vNFciXyEnODFTNREfzk0vqufgc8
Subject: Re: [TLS] Status of X.509v3 TLS Feature Extension?
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: Mon, 28 Apr 2014 16:04:22 -0000

> What's the point if it does not fail-closed?  The client insists that the server provide an OCSP response, but then does not validate it (some notion of freshness is surely part of validation, but no freshness algorithm is indicated).

A client can always ask for an OCSP response, but it is up to that client to decide whether or not the response is satisfactory. If there's a hurricane bearing down on me, I might be willing to accept a stale status response from my local Red Cross chapter, for example. 

> Does the server have to provide OCSP responses for every intermediate CA in the chain?  Or just for the leaf certificate?  Or only for the leaf certificate and those intermediate CAs whose certificates happen to include the proposed TLS feature extension?

Well RFC 6066 says "only one OCSP response may be sent" and while RFC 2560 allows multiple answers, it says that they are a "response for each of the certificates in the request."  Since the server's SSL cert is implied by 6066, and since there is no other way to specify additional certs, then the answer to your questions would be "just the leaf."

	/r$

 --  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: rsalz@jabber.me; Twitter: RichSalz

v2.23.0 | Report a Bug | By Email