Re: [TLS] [pkix] New version of Multiple OCSP mode of Certificate Status extension

[Rob Stradling <[e-mail]>]

In another thread, Kyle H today wrote:
"...why not change the ASN.1 to allow for multiple individual responses in a 
SEQUENCE or SET?"

This is another possible way forward for "Multiple OCSP".

I suppose it would need a new "responseType" OID - something like...
id-pkix-ocsp-multiple  OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }

The "response" OCTET STRING would contain a SEQUENCE OF (or SET OF) 
BasicOCSPResponse (rather than just a single BasicOCSPResponse).

OCSP Clients would signal their support for id-pkix-ocsp-multiple by setting 
this OID in the Acceptable Response Types OCSP Request Extension.  OCSP 
Requests can already contain multiple "CertID"s which reference certificates 
issued by different Issuers, so Clients could explicitly list all the 
certificates they want status information for, rather than rely on the 
Responder to guess which certificates in which certificate chain might be 
relevant.

One disadvantage of this approach is that the various Server software would 
need to be updated before it would be able to "staple" this kind of Response.

However, compared to Yngve's OCSP Response Extension approach, id-pkix-ocsp-
multiple would be kinder to the Responders:
  - Responders would only send the (typically larger) id-pkix-ocsp-multiple 
Responses to Clients that have signalled that they support this responseType.
  - If a Client already has an OCSP Response for some of the Intermediate CA 
Certificate(s) in a chain, it needn't include a CertID for each of them in the 
OCSP Request.  This would further decrease unnecessary network traffic to/from 
the Responders.
  - Responders that use pre-generated Responses can use the same pre-generated 
Responses for both id-pkix-ocsp-basic and id-pkix-ocsp-multiple.

On Monday 02 August 2010 17:45:13 Yngve Nysaeter Pettersen wrote:
> On Mon, 02 Aug 2010 18:26:31 +0200, Peter Gutmann
> 
> <[e-mail]> wrote:
> > "Yngve Nysaeter Pettersen" <[e-mail]> writes:
> >> This issue will not be any different from the current situation; When
> >> they
> >> check OCSP, clients only check the site certificate. If they check
> >> revocation
> >> for intermediates they use CRLs. In fact, for Opera's part, we retrieve
> >> CRLs
> >> while verifying the certificate, OCSP after the certificate has been
> >> checked,
> >> so CRLs are more "dangerous" from that perspective.
> > 
> > Just out of interest, is this a pure performance optimisation, or a tacit
> > recognition of the fact that no public CA cert has ever been revoked no
> > matter
> > how negligently the CA has behaved [0] (and it's unlikely that one ever
> > will
> > because the collateral damage incurred makes it politically untenable),
> > therefore there's no need to spend too much time on revocation checks?
> > 
> > What do other implementations do?  Does anyone check CA certs for
> > revocation
> > when they process a cert chain?
> 
> AFAIK, currently all the major browsers check for OCSP for the site
> certificates (IE for Vista and later, XP requires a preference change
> IIRC), I am not quite sure about CRLs, but checking intermediates is a
> requirement for Extended Validation verification. I didn't see any need to
> distinguish the cases, so we check CRLs for all certificates that identify
> them (and if one certificate have a CRL defined, we require them for all
> certificates below the Root, except the ones we check OCSP for, or we
> remove the padlock)
> 
> Previously, intermediate CA roots were usually issued just to the CA that
> owned the Root, now I am seeing a tendency to issue intermediate CA
> certificates to larger companies, for example. Worst case, it might be
> that it is only a question of time before an intermediate CA have to be
> revoked (That is different from revoking a Root, where the collateral
> damage will be huge if it ever happens, but in such a case the Root key
> has probably been compromised).
> 
> The optimization benefits for my proposals, is that the client need to
> check fewer online revocation resources than before, and they will
> preferably be more up to date, in the best case it does not have to check
> any online resources since the server provided them all. For the CA, there
> will ultimately be less traffic to the server, and it will depend less on
> the number of users, and more on the number of customers.

Rob Stradling
Senior Research & Development Scientist
COMODO - 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.