Dr Stephen Henson wrote:
> Andrew Cooke wrote:
> > However, it seems to me that it would be better if the verifier had only
> > the root CA certificate, and the verifiee supplied not just its
> > certificate, but the intermediate certs in the chain. In this way, the
> > verifier would not need updating if intermediate certs changed (the
> > verifiee would have to get new certs anyway, if an intermediate cert was
> > revoked). Is this possible? And if not, is there a good reason why not
> > (like it's a gaping security hole)?
[...]
> One thing you have to check is to make sure the chain you get passed
> hasn't been illegally "lengthened" by someone using their end user
> certificate and private key to masquerade as a CA or possible several
> CAs.
>
> To do this properly you have to check the intermediate certificates
> really are CA certificates and do some consistency checking and
> workarounds for broken CAs. This is not easy to do.
>
> Anyway. I've added checks like these and some things like trust settings
> to the latest development code. This is quite a hefty change in the way
> things are done and it needs extensive testing but all being well
> something usable will be in 0.9.5.
Does this mean that naieve code that uses OpenSSL is open to this
security hole at the moment, or does something have to be done to turn
it on? If I supply a chain of certificates as the verifiee's
certificate, which includes self-signed, is it detected? I will test
this myself, but have just had to reinstall NT (!) and am busy
re-installing packages etc, so it won't be for a while yet.
Thanks,
Andrew
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
