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

"Yngve Nysaeter Pettersen" <yngve@opera.com> Thu, 01 October 2009 14:00 UTC

Return-Path: <yngve@opera.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 BCBBC28C11A for <tls@core3.amsl.com>; Thu, 1 Oct 2009 07:00:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.813
X-Spam-Level:
X-Spam-Status: No, score=-6.813 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, 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 F0ZRP+iIRIqc for <tls@core3.amsl.com>; Thu, 1 Oct 2009 07:00:08 -0700 (PDT)
Received: from smtp.opera.com (sam.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 6833328C0FC for <tls@ietf.org>; Thu, 1 Oct 2009 07:00:08 -0700 (PDT)
Received: from killashandra.oslo.osa (pat-tdc.opera.com [213.236.208.22]) by smtp.opera.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id n91E1Pos005789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Oct 2009 14:01:31 GMT
Date: Thu, 01 Oct 2009 16:01:28 +0200
To: martin.rex@sap.com
From: "Yngve Nysaeter Pettersen" <yngve@opera.com>
Organization: Opera Software
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15
MIME-Version: 1.0
References: <200909290059.n8T0xNqH020479@fs4113.wdf.sap.corp>
Content-Transfer-Encoding: 7bit
Message-ID: <op.u04jwqjuvqd7e2@killashandra.oslo.osa>
In-Reply-To: <200909290059.n8T0xNqH020479@fs4113.wdf.sap.corp>
User-Agent: Opera Mail/9.65 (Win32)
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: yngve@opera.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:00:09 -0000

On Tue, 29 Sep 2009 02:59:23 +0200, Martin Rex <Martin.Rex@sap.com> 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.

If OCSP was the only game in town, to the end of time, that might work,  
but TLS needs to be able to handle other PKI and revocation structures  
than X.509/PKIX and OCSP.

The main problem here, as I understand it, is that the  
CertificateStatusRequest was (or at least gives every appearance to be)  
intended to support *multiple* certificate status methods, not just OCSP.  
Why else use an enum for the type? With the language in RFC 5246 (quoted  
above) and previous versions of Extensions, a client is not able to (in a  
compliant fashion) to indicate to the server that it supports more than  
one status method, for example the methods OCSP, YACSP (Yet Another  
Certificate Status Protocol) and TTCSP (The Third Certificate Status  
Protocol), of which it prefer TTCSP.

This is important because (future) servers may support only some of the  
alternatives, not all of them, and the client have no way to determine  
which protocol the server supports ahead of sending the Client Hello.

To the best of my understanding, the only realistic way to fix this  
problem is to create a new extension, "status_request_v2", which fixes the  
problem by defining a list. IMO it is going to be difficult to make a good  
errata that changes the RFC 5246 language without making it a free for  
all, causing interpretation problems, and it is not possible to update the  
status_request extension so that is uses CertificateStatusRequestList,  
since there are already implementation (server and client) released that  
uses the current method.


-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************