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