Richard Levitte - VMS Whacker wrote:
>
> From: Dr S N Henson <[EMAIL PROTECTED]>
>
> 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".
>
> Ah, that's what I wanted to know, thanks.
>
> Oh wait, might that be what OCSP_NOVERIFY is for?
>
That would still accept certificates in the reponse itself and would
thus consider any certificate as valid. Not a welcome prospect.
OCSP_NOVERIFY|OCSP_NOINTERN would only use and trust the supplied
certificates but you couldn't then accept other OCSP responder
certificates which passed the normal verify tests.
So whats needed is an option which means "if the signer's certificate is
any of these trust it, otherwise carry on as normal".
> drh> This is also needed to handle broken reponder certificates.
>
> ?
>
Alas some responder certificates break the rules. Some look like
delegated repsonders but don't have the right extensions or aren't
signed by the right CA. If experience is anything to go by it will be
necessary to provide a mechanism which can work around broken responder
certificates (by trusting them as a special case) rather than wait until
the reponder provider fixes their certificates.
> drh> I was talking about being able to automatically handle a trusted
> drh> reponder chain. You could have a situation where a root OCSP responder
> drh> CA has a long lifetime and the OCSP responder certificate has shorter
> drh> lifetime a year or less. With this scenario you can trust the OCSP
> drh> responder root and not have to reinstall the OCSP responder certificate
> drh> every time it expires. This doesn't happen for just any root CA in the
> drh> trusted store: it needs to have an explicit trust setting added to it.
>
> That's an extension to RFC2560, isn't it? I can't really find
> anything in there that views a Trusted Responder in that way.
>
Well I'd argue that it doesn't say what criteria you have to apply to
trust a given public key and there's nothing that specifically prohibits
it. Also in RFC2560:
> - A CA may specify that an OCSP client can trust a responder for the
> lifetime of the responder's certificate. The CA does so by including
> the extension id-pkix-ocsp-nocheck. This SHOULD be a non-critical
> extension. The value of the extension should be NULL. CAs issuing
> such a certificate should realized that a compromise of the
> responder's key, is as serious as the compromise of a CA key used to
> sign CRLs, at least for the validity period of this certificate. CA's
> may choose to issue this type of certificate with a very short
> lifetime and renew it frequently.
If a responder certificate does have a very short lifetime and it isn't
delegated then it isn't practical to trust each as a special case.
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]
