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

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Thu, 01 Oct 2009 16:01:28 +0200

On Tue, 29 Sep 2009 02:59:23 +0200, Martin Rex <[email-masked]> 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: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: Martin Rex <[email-masked]>
Date: Thu, 1 Oct 2009 16:54:52 +0200 (MEST)

Martin Rex wrote:
> >     ClientHello or ServerHello messages, the extensions MAY appear in any

I mis-explained myself:

Servers would always use the existing TLS extension to convey the
OCSP extension for their end entity cert.  If Servers want to convey
additional OCSP responses (for intermediate CA certs and maybe
from different cert paths), they would additionally have to
use a new extension.

-Martin