[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 ********************************************************************
- [TLS] rfc4366-bis: Certificate Status for interme… Yngve N. Pettersen (Developer Opera Software ASA)
- Re: [TLS] rfc4366-bis: Certificate Status for int… Martin Rex
- Re: [TLS] rfc4366-bis: Certificate Status for int… Yngve N. Pettersen (Developer Opera Software ASA)
- Re: [TLS] rfc4366-bis: Certificate Status for int… Nagendra Modadugu
- Re: [TLS] rfc4366-bis: Certificate Status for int… Rob Stradling
- Re: [TLS] rfc4366-bis: Certificate Status for int… Yngve Nysaeter Pettersen
- Re: [TLS] rfc4366-bis: Certificate Status for int… Martin Rex