Re: [TLS] New version of Multiple OCSP mode of Certificate Status

Martin Rex <mrex@sap.com> Wed, 04 August 2010 19:15 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80F4F3A6886; Wed, 4 Aug 2010 12:15:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.659
X-Spam-Level:
X-Spam-Status: No, score=-9.659 tagged_above=-999 required=5 tests=[AWL=0.590, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id au88X1UDuRuN; Wed, 4 Aug 2010 12:14:59 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 111FD3A6831; Wed, 4 Aug 2010 12:14:58 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o74JFNnv016814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Aug 2010 21:15:28 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201008041915.o74JFM9X009405@fs4113.wdf.sap.corp>
To: yngve@opera.com
Date: Wed, 04 Aug 2010 21:15:22 +0200
In-Reply-To: <op.vgxe0necqrq7tp@acorna.invalid.invalid> from "Yngve N. Pettersen" at Aug 4, 10 08:30:13 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: pkix@ietf.org, tls@ietf.org
Subject: Re: [TLS] New version of Multiple OCSP mode of Certificate Status
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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, 04 Aug 2010 19:15:01 -0000

Yngve N. Pettersen wrote:
> 
> Opera, and AFAIK MSIE, retrieves these specified certificates in an  
> attempt to complete the incomplete chain that the server sent, and there  
> are too many of those servers around (As an example, try  
> https://member.ruten.com.tw/user/login.htm in a few browsers, which is at  
> the time of writing missing a Versign G2 intermediate cert).

You mean that this web-server is sending a server certificate from a
certification path that ends at a self-signed rootCA which the browser
already trusts, but the server does not include the intermediate CA
certificate that is necessary to validate the server certificate?

An implementation compliant to any of the TLS v1.x specifications
would have to abort the handshake with such a server due to an
clear protocol violation.  The server MAY omit the self-signed
rootCA cert at the end of his certification path, but omitting
any of the intermediate CA certs is not permitted.

http://tools.ietf.org/html/rfc5246#page-48


-Martin