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

[Rob Stradling <[e-mail]>]

On Wednesday 04 August 2010 15:40:05 Yngve Nysaeter Pettersen wrote:
> On Tue, 03 Aug 2010 21:46:38 +0200, Rob Stradling
> 
> <[e-mail]> wrote:
> > In another thread, Kyle H today wrote:
> > "...why not change the ASN.1 to allow for multiple individual responses
> > in a
> > SEQUENCE or SET?"
> 
> I suspect that this is about responses for multiple certificates for the
> same issuer.

I suspect not.  BasicOCSPResponse already allows a single Response to contain 
status information about multiple certificates for the same issuer.

In fact, BasicOCSPResponse already allows a single Response to contain status 
information about multiple certificates from *multiple issuers*.  The problem, 
of course, is that a BasicOCSPResponse may only be signed by a single entity, 
so this kind of Response could only ever be useful in a "local configuration 
of OCSP signing authority" (RFC 2560 section 4.2.2.2 option 1) context.

> I am not sure how well this will work for clients like Opera, since we are
> associating the response with the URL for retrieving it, we don't add it
> to a repository.

First you wanted to try to avoid requiring updates to Servers that already 
support OCSP "stapling".  Are you now suggesting that Clients cannot be 
updated either?

> I also suspect that we will seldom encounter a certificate that was
> matched by that response anyway.
> 
> > 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).
> 
> If you mean that the sequence should include the OCSP responses for each
> intermediate, as well as the end entity certificate,

Yes, I do mean that.

> that will not work unless the responder is signing with a certificate issued
> directly from the Root, and which is somehow designated as the signer fore
> each > certificate in the chain.

I say it will work.  You seem to be assuming that each BasicOCSPResponse in 
the SEQUENCE/SET would contain a signature generated by the same 
key/certificate.  I never said that.  Rather, each BasicOCSPResponse in the 
SEQUENCE/SET would contain a signature generated by a key/certificate that is 
authorized to sign it.  If the Responder is not authoritative for one (or 
more) certificates in the chain, then it could either i) "staple" a valid 
BasicOCSPResponse obtained from another Responder, or ii) simply not include a 
BasicOCSPResponse for this certificate (which would cause the Client to try 
looking somewhere else for status info about that certificate).

> If the signer of the end entity cert was allowed to sign responses for the
> intermediate, it would be allowed to create the revocation information
> about its own status (which should only be presented by the issuer
> itself), so it would need to be a designated responder cert issued by the
> Root.
> 
> Such a designated cert would probably become logistical problem for a Root
> hierarchy that have many independent intermediates, and essentially the
> Root issuer would have to maintain a revocation service for all subCAs.

This is a different idea.

If we could designate the Root Certificate and/or a designated Responder 
certificate issued by the Root Certificate as "Authorized Responders" for 
signing OCSP Response information for all certificates in the chain, then the 
existing ASN.1 would be sufficient for "Multiple OCSP".
However, Clients, Servers and Responders would all need code updates.  Also, 
there would be nothing technically to prevent Root Certificate A from cross-
certifying Root Certificate B (without Root Certificate B's consent), which 
would give Root Certificate A the power to make up OCSP status information for 
all certificates that chain up to Root Certificate B.

> Storing the full signed response from the issuer in the response would
> prevent such a logistical problem, but would create a larger response,
> which might cause other logistical problems.

"Storing the full signed response from the issuer in the response" is what my 
previous post proposed.

My proposal wouldn't "create a larger response", but it would require ASN.1 
changes.

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.