Richard Levitte - VMS Whacker wrote:
> 
> From: Dr S N Henson <[EMAIL PROTECTED]>
> 
> drh> >    -- the CA who issued the certificate in question
> drh> >    -- a Trusted Responder whose public key is trusted by the requester
> drh> >    -- a CA Designated Responder (Authorized Responder) who holds a
> drh> >       specially marked certificate issued directly by the CA, indicating
> drh> >       that the responder may issue OCSP responses for that CA
> drh> >
> drh> > I'm talking about the "Trusted Responder", and what I want to be able
> drh> > to do is tell OpenSSL in my client is that one specific certificate
> drh> > given by me shalle be used to verify the signature.  This has nothing
> drh> > to do with chain verification, it's just about the verification of the
> drh> > response signature, since I've already told it what public key I
> drh> > trust.
> drh> >
> drh>
> drh> Well that's something next on the list. You can pass in a list of "extra
> drh> certificates" in the verify function and some flags. One flag will be
> drh> "automatically trust these and don't try to verify them".
> 
> :-) Actually, for the "Trusted Responder" case, one shouldn't even
> need to handle an OCSP signing certificate.  Read that line again, all
> it says is "pubkey".  It says absolutely nothing about certificates in
> that particular case.  I could as well configure my client software
> with a key.pem that contains exactly this:
> 
>      -----BEGIN PUBLIC KEY-----
>      ...
> 
>      -----END PUBLIC KEY-----
> 
> ... and it should be happy with that.  That's what RFC2560 really
> implies.  One would just do it via certificates because it's more
> comfortable that way...
> 

There are also problems with just using public keys. You need some way
to determine which public key signed the OCSP response. If the response
doesn't include the signer's certificate and it is identified by the
subject name (which is true in all the examples I've seen so far) then
you can't do that with just the public key.

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]

Reply via email to