On Thu, 2005-01-20 at 15:16 -0500, Rich Salz wrote: > > My point is that OpenSSL does work even if the list of certificates does > > not comply to to RFC2246 ... which seems bad to me > > What's bad about it? I suppose there's a DoS risk if you have to look > through a big cert list to build a chain, rather than just checking > "n+1". But is that worth, e.g., potentially breaking interop with > existing (buggy, admittedly) SSL implementations? > > Did you have another rationale for the change?
My "internal" rationale had more to do with consistency in the tools and solutions we offer: We have Java based and C based implementations of the same security code. In this scenario the Java one actually presents the user with an error while the C one works which ends up being somewhat confusing for users. If you feel that tightening up is not worth the risk that is fine. We'll either just carry a patch or ignore the problem. I really just wanted to gauge the situation. Also, in general I feel that more compliance checking (especially if it doesn't really cost anything) is better than being more permissive, but since this is a fairly mature area of development I would understand if the risks outweigh the benefits. /Sam > /r$ > -- Sam Meder <[EMAIL PROTECTED]> The Globus Alliance - University of Chicago 630-252-1752 ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
