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

"Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com> Tue, 07 July 2009 20:05 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 55DDC3A6A88 for <tls@core3.amsl.com>; Tue, 7 Jul 2009 13:05:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.032
X-Spam-Level:
X-Spam-Status: No, score=-6.032 tagged_above=-999 required=5 tests=[AWL=0.567, 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 uYYeaYZL+sqc for <tls@core3.amsl.com>; Tue, 7 Jul 2009 13:05:01 -0700 (PDT)
Received: from smtp.opera.com (sam.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id F3EAC3A67F0 for <tls@ietf.org>; Tue, 7 Jul 2009 13:05:00 -0700 (PDT)
Received: from nimisha.invalid.invalid (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id n67K1P5P021969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <tls@ietf.org>; Tue, 7 Jul 2009 20:01:29 GMT
Date: Tue, 07 Jul 2009 22:01:22 +0200
To: "tls@ietf.org" <tls@ietf.org>
From: "Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com>
Organization: Opera Software AS
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-ID: <op.uwpq8kb0qrq7tp@nimisha.invalid.invalid>
User-Agent: Opera Mail/9.26 (Win32)
Subject: [TLS] rfc4366-bis: Certificate Status for intermediate CA certificates
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/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: Tue, 07 Jul 2009 20:05:02 -0000

Hi,

The current Certificate Status request and response is currently only able  
to handle a single OCSP respose, for the site certificate.

A number of CAs have started to put OCSP URLs in their intermediate  
certificates, and using these URLs would help provide a more timely  
revocation information for Intermediate CA certificates too (not that it  
should normally be needed for CA certificates), not just for site  
certificates.

However, CAs have already been concerned about the network traffic  
generated by clients just performing OCSP checks directly, not via the  
Certificate Status request, and I am aware of at least one case were the  
number of such requests caused serious problems for a CA. Adding direct  
retrieval of OCSP for the intermediates, and therefore significantly  
increasing the network traffic (particularly after the Certificate Status  
extension starts handling the majority of responses) is therefore not  
recommended.

The problem with OCSP traffic for intermediates could be solved if the  
client could get the responses via the TLS server, similar to what the  
Certificate Status extension already do for site certificates.

But given the definition of the Certificate Status extension it cannot be  
used to provide OCSP information for intermediates, so a new extension  
will be needed.

My suggestion would be to add an extension to indicate support for  
multiple Certificate Status responses, e.g. "Certificate Chain Status",  
which the server have to use in the Server Hello extension list, followed  
either by a new Certificate Chain Status handshake record containing an  
array of status responses, or multiple Certificate Status messages.

Whichever record method is chose, in either case the list of responses  
must either be in the sequence the certificates are placed in the chain,  
or the responses have to be matched with the certificate somehow. An issue  
with following the sequence is that some CAs are using cross-signed  
certificates linking to multiple roots, e.g. to allow EV chains (which in  
many cases chain to new Roots) to be validated by legacy clients, or new  
CAs have their certificate signed by a CA already in most Rootstores to be  
able to enter the market.

Based on this I would suggest a new record, at least for the  
intermediates, in which each entry in the list identifies the Certificate  
it is the OCSP response for. This might be the same key used to request  
the OCSP response from the server, or some other way to identify the  
certificate (name, serialnumber, pubkeyhash, etc.)

Thoughts?



-- 
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
********************************************************************