Re: [TLS] rfc4366-bis: Certificate Status for intermediate CA

Martin Rex <Martin.Rex@sap.com> Thu, 01 October 2009 14:53 UTC

Return-Path: <Martin.Rex@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 E6C5C3A684B for <tls@core3.amsl.com>; Thu, 1 Oct 2009 07:53:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.028
X-Spam-Level:
X-Spam-Status: No, score=-6.028 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 T-p4R3MhISBf for <tls@core3.amsl.com>; Thu, 1 Oct 2009 07:53:32 -0700 (PDT)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id E54003A67A8 for <tls@ietf.org>; Thu, 1 Oct 2009 07:53:31 -0700 (PDT)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n91EssVa007234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Oct 2009 16:54:54 +0200 (MEST)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200910011454.n91EsqXT002903@fs4113.wdf.sap.corp>
To: martin.rex@sap.com
Date: Thu, 1 Oct 2009 16:54:52 +0200 (MEST)
In-Reply-To: <200909290059.n8T0xNqH020479@fs4113.wdf.sap.corp> from "Martin Rex" at Sep 29, 9 02:59:23 am
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: tls@ietf.org
Subject: Re: [TLS] rfc4366-bis: Certificate Status for intermediate CA
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: martin.rex@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: Thu, 01 Oct 2009 14:53:33 -0000

Martin Rex wrote:
> 
> Yngve N. Pettersen wrote:
> > 
> > However, sending two CertificateStatusRequest extensions in the same  
> > ClientHello is forbidden by RFC 5246 sec 7.4.1.4:
> > 
> >     When multiple extensions of different types are present in the
> >     ClientHello or ServerHello messages, the extensions MAY appear in any
> >     order.  There MUST NOT be more than one extension of the same type.
> 
> How about always using the existing extension for the OCSP response
> for the server certificate, and using a new extension for OCSP responses
> for other certificates (like intermediate CA certs), probably unsorted.
> 
> PKIs with flat hierarchies (Server-cert signed by self-signed CA cert)
> use only the original extension.  Servers with certs from multi-level
> CA hierarchies need to use the new extension if they want to send
> additional OCSP responses.

I mis-explained myself:

Servers would always use the existing TLS extension to convey the
OCSP extension for their end entity cert.  If Servers want to convey
additional OCSP responses (for intermediate CA certs and maybe
from different cert paths), they would additionally have to
use a new extension.

-Martin