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

["Yngve Nysaeter Pettersen" <[e-mail]>]

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 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.
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, 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.

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.

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.


-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************