Re: [TLS] rfc4366-bis: Certificate Status for intermediate CA certificates
"Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com> Mon, 28 September 2009 21:58 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 3E98B3A68BB for <tls@core3.amsl.com>; Mon, 28 Sep 2009 14:58:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.17
X-Spam-Level:
X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=-1.429, BAYES_20=-0.74, 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 SU4sIHDYJmqy for <tls@core3.amsl.com>; Mon, 28 Sep 2009 14:58:05 -0700 (PDT)
Received: from smtp.opera.com (sam.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id D006D3A682E for <tls@ietf.org>; Mon, 28 Sep 2009 14:58:04 -0700 (PDT)
Received: from acorna.oslo.opera.com (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 n8SLxDgV005295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <tls@ietf.org>; Mon, 28 Sep 2009 21:59:14 GMT
Date: Mon, 28 Sep 2009 23:59:10 +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
References: <op.uwpq8kb0qrq7tp@nimisha.invalid.invalid>
Content-Transfer-Encoding: 8bit
Message-ID: <op.u0zl0wlcqrq7tp@acorna.oslo.opera.com>
In-Reply-To: <op.uwpq8kb0qrq7tp@nimisha.invalid.invalid>
User-Agent: Opera Mail/9.65 (Win32)
Subject: Re: [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: Mon, 28 Sep 2009 21:58:08 -0000
Hello all, After the short discussion about this topic in Stockholm, I've now started to look into how to define a multi-certificate status extension. My current thinking is to achieve this with the minimum number of changes needed to add the new status information to the protocol. In my opinion that would mean adding a new enum, ocsp_multi, to the CertificateStatusType enum, the same OCSPStatusRequest record (alternatively a list of them, but I do not think that is desirable), and a new MultipleOCSPResponse member to the response union in the CertificateStatus message which contain a list of OCSPResponse records. For backward compatibility, clients supporting both this new mode and the old one, so that they can use the old mode with servers that only support that mode, will have to send two CertificateStatusRequest extension in the ClientHello, one for the "ocsp" type, and one for the "ocsp_multi" type. 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. Given this wording, and the fact that the extension is defined as CertificateStatusRequest and not CertificateStatusRequestList which consist of one or more CertificateStatusRequest items, it does not seem possible for clients to support more than one certificate status mode at a time, and that they will with prior agreement with the server to select which method to use. Is my understanding correct? If so, can anything (realistically) be done to fix the problem short of having to use a new extension? If the problem cannot be fixed without a new extension, I would suggest that a new certificate status extension, e.g status_request_v2, is defined, which defines a CertificateStatusRequestList vector of CertificateStatusRequest items (the same as is currently used in status_request (v1) ). Thought? On Tue, 07 Jul 2009 22:01:22 +0200, Yngve N. Pettersen (Developer Opera Software ASA) <yngve@opera.com> wrote: > 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