Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

From: "Santosh Chokhani" <[email-masked]>
Date: Sat, 11 Nov 2006 11:39:28 -0800

Russ,

From pragmatic viewpoint, when the AIA in two certificates point to the
same Responder, it is the subscriber and the issuer CA.  That is why
pre-cached responses in some of the products always contain the CA
certificate response, if the Responder is authorized to provide CA
certificate revocation status.

The above is a common implementation and avoids combinatorial problem.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: Friday, November 10, 2006 10:53 PM
To: Dave Engberg; Michael Myers
Cc: [email-masked]; Sam Hartman
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Dave:

>I agree with Mike, and disagree with Sam's original assertion.
>
>A keyless responder with pre-signed responses can be fully compliant
with
>the mandatory requirements of RFC 2560.  This is reflected in both the
>"letter of the law" and in every OCSP relying party app/plug-in I've
tested
>(which can all work with keyless caching responders).

After a face-to-face discussion with Sam, I think that he is 
correct.  Let me try to explain the case that he discovered.

Assume that the relying party has a certification path to validate, 
and two of the certificates in the path contain AIA extensions that 
point to the same OCSP Responder.

The relying party generates an OCSP request, including both of the 
certificates.  RFC 2560 allows one or more certificate to be named in 
the OCSP Request (SEQUENCE OF Request), and I could not find any text 
to indicate that support for more than one element in this sequence 
is not mandatory.

The OCSP Responder generates an OCSP response for both of the 
certificates (SEQUENCE OF SingleResponse).  This response is covered 
by one signature.

So, there are three cases to consider:

(1) OCSP Responder with a signature key - there is not a concern 
here.  The OCSP Responder builds the response and signs it.

(2) OCSP Responder that can relay to a server with a signature key - 
there is not a concern here.  The OCSP Responder forwards the request 
to the server with a signature key, the server builds the response 
and signs it, and then the signed response is sent back to the 
original responder.

(3) OCSP Responder with a bunch of cached responses - there is a 
concern here.  The responder cannot respond to the multi-certificate 
request unless responses for every possible combination of requested 
certificates is computed and cached.  This would be computationally 
prohibitive for a certificate population of any significant size.

The only way forward that I see is RFC 2560bis.

Russ