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

mrex@sap.com (Martin Rex) Mon, 28 April 2014 18:02 UTC

Return-Path: <mrex@sap.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 6C0A61A6FCE for <tls@ietfa.amsl.com>; Mon, 28 Apr 2014 11:02:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 hVdZqXwtvH-m for <tls@ietfa.amsl.com>; Mon, 28 Apr 2014 11:02:22 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC841A6FBA for <tls@ietf.org>; Mon, 28 Apr 2014 11:02:21 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s3SI2I0A024126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Apr 2014 20:02:18 +0200 (MEST)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F669@USMBX1.msg.corp.akamai.com>
To: "Salz, Rich" <rsalz@akamai.com>
Date: Mon, 28 Apr 2014 20:02:18 +0200
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20140428180218.C805D1ACE1@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zwy7M9l5SDx0ZufQ4HdVrIMXdJo
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
Reply-To: mrex@sap.com
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 18:02:23 -0000

Salz, Rich wrote:
> 
> 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."

AFAIK, rfc2560 allows the OCSP response to contain the status
of more than one certificate, but it can only be signed by a single
OCSP responder.  I assume that each certificate in the server's
certificate refers to different OCSP responder.

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 may happen more often with the certificate paths that are used
for backward compatibility, where the current 2048-bit RSA rootCA cert is
included as a cross-CA certificate to an old 1024-bit RSA trust anchor.

Google seems to be using two cross-certs in their forward path that
you may not be aware of if you look at the path of the server cert as
verified by a recent browser.

-Martin