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

Geoffrey Keating <geoffk@geoffk.org> Mon, 28 April 2014 19:44 UTC

Return-Path: <geoffk@geoffk.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 520A81A6F0A for <tls@ietfa.amsl.com>; Mon, 28 Apr 2014 12:44:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 UJf4THeqEgyN for <tls@ietfa.amsl.com>; Mon, 28 Apr 2014 12:44:24 -0700 (PDT)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) by ietfa.amsl.com (Postfix) with ESMTP id ADC711A064C for <tls@ietf.org>; Mon, 28 Apr 2014 12:44:24 -0700 (PDT)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 1EDAD33CF8A; Mon, 28 Apr 2014 19:44:24 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: mrex@sap.com
References: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F669@USMBX1.msg.corp.akamai.com> <20140428180218.C805D1ACE1@ld9781.wdf.sap.corp>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: Mon, 28 Apr 2014 12:44:24 -0700
In-Reply-To: <20140428180218.C805D1ACE1@ld9781.wdf.sap.corp>
Message-ID: <m2r44hw86f.fsf@localhost.localdomain>
Lines: 14
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZeVb29IL91R--TMZjMSD9kq-fq4
Cc: "tls@ietf.org" <tls@ietf.org>
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 19:44:28 -0000

mrex@sap.com (Martin Rex) writes:

> Processing multiple OCSP responses from the TLS multiple certificate status
> extension will also be interesting for TLS client that essentially throw
> away everything but the Server certificate from the Server's TLS Certificate
> handshake message and perform a new path discovery, because the resulting
> path may be different from the one that was sent by the server.

This is only a problem if the new path discovery might use
certificates which weren't sent from the server (built-in
intermediates or ones fetched from the web), for which of course the
server won't have sent OCSP responses.  Another way to put this is
that the server needs to send all necessary intermediates for OCSP
stapling to work properly.