Hello Steve, Stephen Henson via RT wrote: > [[EMAIL PROTECTED] - Mon Feb 10 20:02:40 2003]:
>>OK. >>I should clarify myself: >>It is to do it correctly, but not needed to fix the actual problem. >> >>>However option 4 easy to do and could be argued as being a "bug fix". >> >>OK. >> >>Perhaps something like: >> build the chain only with the certs supplied with >> SSL_CTX_add_extra_chain_cert() > Perhaps I should clarify myself too :-) > > The current situation is not good. If the primitive auto chain building > comes up with the wrong answer then there isn't any easy method I can > think of that will allow it to fix things. ACK > Giving no certificate store at all and doing all its own verification > might work but it's a hack. > > As a result IMHO we need a way to do *something* in OpenSSL 0.9.7X. > > If it is decided that a 0.9.7X fix is needed then this should be a > minimal bug fix solution that keeps the changes in functionality down to > a minimum but gives the application some method of correcting things > when the chain build breaks. ACK > For that maybe a new flag or possibly auto disable of the chain build if > any extra certs are added. After all if the application is supplying > extra certs it presumably is expecting the auto chain build to fail > anyway? I can't see any legitimate reason for supplying extra certs > *and* having auto chain build. That confused me too. > The extra certs would be sent verbatim which is what 0.9.7 currently > does anyway. > Doing things properly will need new functionality and new functions and > possibly break existing applications. As such that should be a 0.9.8 target. ACK > For example what purpose and trust settings do you use in the chain > building? The defaults will be SSL server for servers and SSL client for > clients but some applications might need something different which the > current primitive chain build will handle but the "correct" version wont. I don't think that we should do there to much checks. We should check: * the validity period (begin & end) of all certs * the trust settings for all certificates * the purpose for the CA certs I don't think we really should check the purpose of the own certificate. (At least not break if it doesn't matches.) A mismatching purpose should result in a warning but not in an error. But since OpenSSL has no warnings... If the purpose of the certificate doesn't match, the peer should decide if a connection is established. In special cases it is usefull to use a client cert for a server and a server key for a client. Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
