RE: Clarification request on RFC 2560

["Andrew Sciberras" <andrews@xxxxxxxxxxxxx>]

Ryan,

I am at a loss to understand how the scenario which you have described below
will work.

Firstly, Your OCSP responder has 3 different signing certificates. Although
issued by different CA's, each certificate will  contain the same key data.

When you receive a single request that asks for the status of 3 unrelated
certificates, which certificate will you sign the single response with?

>From what I can see, section 4.2.2.2 states:
"..... They MUST reject the response if the certificate required to validate
the signature on the
 response fails to meet at least one of the following criteria:

   1. Matches a local configuration of OCSP signing authority for the
   certificate in question; or

   2. Is the certificate of the CA that issued the certificate in
   question; or

   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
   extension and is issued by the CA that issued the certificate in
   question.
"

The point that must be satisfied by the scenario described above is #3
which, amongst other things, states that the signing certificate must be
issued by the CA that issued the certificate in question.
Although all three of your signing certificates have the same keys,
shouldn't the OCSP client have to validate the response by looking at the
actual signing certificate and verifying that it was actually issued by the
CA in question?

How should the OCSP Client proceed at this point, since there are 3
unrelated certificates in question, with only one certificate signing the
response?

Andrew Sciberras
Software Engineer
Adacel Technologies Ltd





> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of Ryan Hurst
> Sent: Friday, September 14, 2001 3:31 AM
> To: 'Denis Pinkas'; pkix
> Cc: Mike Myers; Ambarish Malpani
> Subject: RE: Clarification request on RFC 2560
>
>
>
> Denis --
>
> 	I agree this is not terribly clear in the RFC and your
> question is a
> common one (maybe we can get some amended text in this regard
> in the RFC?).
> In MOST of the implementations I have looked at (ours
> included) the certs
> portion of the structure is used to provide the client with
> the certificates
> associated with the signature on the response.
>
> Consider this scenario; I have a single OCSP responder
> configured to serve
> responses for 3 un-related certificate authorities. The
> responder has CA
> delegated certificates (each CA has certified the same
> request and key pair)
> from each of these certificate authorities (as per section
> 2.2 and 4.2.2.2
> of the OCSP RFC [2560]). I have a client who sends a single
> OCSP request for
> statuses for 3 unrelated certificates (one from each of the previously
> mentioned CAs) to the responder. For the responder to produce
> a response
> this response that could be verified by the client it needs to provide
> certificates that could be chained back to the issuer of the
> certificates in
> question, since a ResponderID only provides the options to
> identify the
> responder byName or byKey the responder needs to provide the
> client with the
> certificates associated with the response. In this case 3 different
> certificates (once again all with the same key material) thus
> allowing the
> client to establish that response was signed by an authority
> delegated by
> each issuing CA.
>
> Using the certs[0] for a single responder chain would then
> limit a responder
> to serving responses for one CA in a delegated scenario as
> described above.
>
> Also the CA delegated scenario described by section 2.6 of
> the RFC [2560]
> states:
>
> "A certificate's issuer explicitly delegates OCSP signing authority by
> issuing a certificate containing a unique value for
> extendedKeyUsage in the
> OCSP signer's certificate. This certificate MUST be issued
> directly to the
> responder by the cognizant CA"
>
> I interpret this to mean that only the issuer of the certificate must
> explicitly delegate to this authority, as such when verifying
> a response in
> this case I would only need the signing certificate not its chain.
>
>
> Ryan M. Hurst
> ValiCert, Inc.
>
>
>  -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
> Sent: Thursday, September 13, 2001 3:20 AM
> To: pkix
> Cc: Mike Myers
> Subject: Clarification request on RFC 2560
>
>
>
> In RFC 2560 section 4.2.1 (OCSP Response), we have
>
> BasicOCSPResponse       ::= SEQUENCE {
>       tbsResponseData      ResponseData,
>       signatureAlgorithm   AlgorithmIdentifier,
>       signature            BIT STRING,
>       certs                [0] EXPLICIT SEQUENCE OF
> Certificate OPTIONAL }
>
> Usually every ASN1 field is explained, but in that document
> the certs field
> is not explained.
>
> Should that optional field be interpreted to carry a sequence
> of possibly
> useful certificates ?
>
> Denis
>