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

[Rob Stradling <[e-mail]>]

> If so, can anything (realistically) be done to fix the problem short of
> having to use a new extension? 

Yngve, why don't we ask the PKIX WG to extend RFC2560?

We could define a new responseType, perhaps something like...
id-pkix-ocsp-multi     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }

Whereas the ResponseBytes for id-pkix-ocsp-basic can only contain certificate 
status information for 1 or more certificates issued by the *same* CA, the 
ResponseBytes for id-pkix-ocsp-multi would be able to contain certificate 
status information for 1 or more certificates issued by *multiple* CAs.  
(Each of the multiple CAs would contribute 1 signature to each 
id-pkix-ocsp-multi OCSPResponse).

A TLS server would return an id-pkix-ocsp-multi OCSPResponse in response to 
your proposed "ocsp_multi" CertificateStatusRequest (or it could return an 
id-pkix-ocsp-basic OCSPResponse if no id-pkix-ocsp-multi OCSPResponse was 
available).  For the already defined "ocsp" CertificateStatusRequest, a TLS 
server would always return an id-pkix-ocsp-basic OCSPResponse.

With this approach, there would never be a need to send two or more 
CertificateStatusRequest extensions, so you wouldn't have to "use a new 
extension".

> My current thinking is to achieve this with the minimum number of changes
> needed to add the new status information to the protocol.

Perhaps my suggestion above is more intrusive than you're looking for.  
However, I think it would have additional benefits that, whilst arguably 
outside the scope of this TLS WG, are worth considering...

There may be cases where an OCSP Client and an OCSP Responder support 
id-pkix-ocsp-multi, but the TLS Server (with which the OCSP Client wishes to 
communicate) does not support "ocsp_multi".
There may be cases where OCSP Clients wish to obtain certificate status 
information for S/MIME certificates, Code Signing Certificates, etc, where 
there is no TLS handshake in which to send a CertificateStatusRequest.

With my suggestion, an OCSP Client would be able to specify id-pkix-ocsp-multi 
in the RFC2560 "AcceptableResponses" OCSP Request extension.  This would 
allow the OCSP Responder to return an id-pkix-ocsp-multi OCSPResponse, 
thereby reducing the number of OCSP Requests that the OCSP Client needs to 
send and reducing the traffic that the OCSP Responder needs to handle.

A further suggestion...
An OCSP Client might want to (i) send an explicit list of certificates from 
multiple CAs for which it requires certificate status information, or it 
might want to (ii) identify just the end-entity certificate and have the OCSP 
Responder automatically include certificate status information for all other 
certificate(s) (from multiple CAs) that the Responder believes to be relevant 
for chain building.
We could define two different responseType values for these two cases.  
Perhaps...
id-pkix-ocsp-multi-explicit     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
id-pkix-ocsp-multi-auto     OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }

On Monday 28 September 2009 22:59:10 Yngve N. Pettersen (Developer Opera 
Software ASA) wrote:
> 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) <[e-mail]> 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?

-- 
Rob Stradling
Senior Research & Development Scientist
C·O·M·O·D·O - Creating Trust Online
Office Tel: [phone]
Office Fax: [phone]
www.comodo.com

Comodo CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.