Richard Levitte - VMS Whacker wrote:
>
> From: Dr S N Henson <[EMAIL PROTECTED]>
>
> drh> Yes, you need to add the CA to the trusted store and change the trust
> drh> setting of the root CA to support OCSPSigning then it will verify for
> drh> any issuer CA in the OCSP request. This is intended to support the
> drh> "global responders" which give info about multiple CAs and have a
> drh> separate certificate chain.
>
> Are we talking about the same thing? In RFC2560 section 2.2, the
> following possible signers are listed:
>
Partly :-)
> 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
>
> I'm talking about the "Trusted Responder", and what I want to be able
> to do is tell OpenSSL in my client is that one specific certificate
> given by me shalle be used to verify the signature. This has nothing
> to do with chain verification, it's just about the verification of the
> response signature, since I've already told it what public key I
> trust.
>
Well that's something next on the list. You can pass in a list of "extra
certificates" in the verify function and some flags. One flag will be
"automatically trust these and don't try to verify them".
This is also needed to handle broken reponder certificates.
The ideal situation would be to be able to add trust settings to a
single end user (err end responder...) certificate in the trusted store
and have that work automatically. Unfortunately that would need a
complete rewrite of the verify code :-(
> I definitely do *not* want to have to tell OpenSSL that I trust the CA
> of my "Trusted Responder" certificate, because that might imply that I
> trust any certificate that CA has produced.
>
> What you seem to talk about is the "CA Designated Responder"
> certificate, which is a completely different story.
>
Err no designated reponders are automatically handled and need no
special configuration.
I was talking about being able to automatically handle a trusted
reponder chain. You could have a situation where a root OCSP responder
CA has a long lifetime and the OCSP responder certificate has shorter
lifetime a year or less. With this scenario you can trust the OCSP
responder root and not have to reinstall the OCSP responder certificate
every time it expires. This doesn't happen for just any root CA in the
trusted store: it needs to have an explicit trust setting added to it.
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]
