Richard Levitte - VMS Whacker wrote:
>
> From: [EMAIL PROTECTED] (Peter Gutmann)
>
> pgut001> That may be a Netscape-ism, in earlier (and possibly still
> pgut001> current) versions of their OCSP client they did something
> pgut001> funny like requiring that responses be signed by some CA cert
> pgut001> directly involved in issuing the cert, rather than a special
> pgut001> OCSP responder cert like other vendors seem to be using.
>
> "rather than" is perhaps not what you really meant. Both are correct
> options accordning to RFC2560, section 2.2 (Response):
>
> [...]
> All definitive response messages SHALL be digitally signed. The key
> used to sign the response MUST belong to one of the following:
>
> -- the CA who issued the certificate in question
> -- a Trusted Responder whose public key is trusted by the requester
> -- a CA Designated Responder (Authorized Responder) who holds a
> specially marked certificate issued directly by the CA, indicating
> that the responder may issue OCSP responses for that CA
>
> According to what you say, Netscape required the first variant (which
> is of course not sufficient to be RFC-compliant), while the other do
> the second, or is it the third or both?
>
Well I can't be sure what Netscape does until I can use the OpenSSL code
to implement a responder. However its UI supports precisely one of three
options.
1. No OCSP checks.
2. OCSP checks on addresses in certificates authorityInfoAccess
extension.
3. A single global OCSP responder with a user configured certificate and
URL.
This isn't a great deal of use because neither Thawte nor Verisign
includes the OCSP responder address in authorityInfoAccess.
Also neither responder is a global OCSP responder they just handle
Thawte or Verisign, not both, I don't know about other CAs.
Wrt certificates.
The Valicert responder has a special certificate which chains to an
independent root CA which is unconnected with Thawte.
The Verisign responder has several OCSP certificates signed by the
relevant root CA. Which certificate you get depends on the CA you are
querying.
What this means is that if you check a two tier Verisign CA such as the
secure server CA you will check a certificate signed by the root CA. The
responder has a delegated certificate signed by the root CA. This then
comes into the "CA designated responder" case.
If you have a three tier CA such as the Class 1 then you check an end
user certificate signed by an intermediate CA which is itself signed by
the root CA. The responder again has what looks like a delegated
certificate signed by the root CA.
My interpretation of this is that it does not come under the "CA
designated responder case" because the reponder certificate is signed by
the root CA and not the CA that issued the end user certificate which
would be the intermediate CA.
However I suppose I should ask this on the PKIX list to be sure.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
