Re: [TLS] draft-pettersen-tls-ext-multiple-ocsp questions

[Martin Rex <[e-mail]>]

Jim Schaad wrote:
> 
> There are three models for doing OCSP, as near as I can tell this draft only
> addresses two of those models.
> 
> 1.  The RP uses a single OCSP server that will issue the OCSP responses
>     for all of the certificates in a chain.
> 2.  The CA directly issues OCSP responses for the certificates that it
>     issues (thus they replace direct CRLs)
> 3.  The CA issues a certificate to the OCSP responder (thus they replace
>     indirect CRLs).
> 
> The first two are covered as only the certificates in the CA chain and the
> OCSP responses are needed, however the last model would require that
> additional certificates and potentially CRLs be transported so that the
> indirect certificate can be validated as part of processing the OCSP
> responses.


If your above enumeration is supposed to reflect the enumeration
from rfc2560 section 4.2.2.2

   http://tools.ietf.org/html/rfc2560#section-4.2.2.2

then (1) seems unusable for the purpose of OCSP response stapling
within a TLS extension.  The "local" within
"Matches a local configuration of OCSP signing authority" really
refers to the TLS server when acting as RP to obtain the OCSP
responses.  That "local" may be meaningless even for other hosts
of the same site (and in the extreme case, might even be meaningless
for a different process on the same host).

(3) does _not_ imply an indirection.  A CA could issue an OCSP signer
cert (as well as a CRL signer cert) as a self-issued non-CA cert.
In the OCSP case, if the OCSP signer case, if the OCSP response is
not signed by the same CA key(cert) that signed the certificate in
question, then that OCSP signer cert ought to be included within
the OCSP response (BasicOCSPResponse->certs field), so that the
signature validation can be securely performed by the RP.



-Martin