In message <[EMAIL PROTECTED]> on Thu, 18 Nov 2004 13:45:38 +0100, "Dr. Stephen Henson" <[EMAIL PROTECTED]> said:
steve> On Thu, Nov 18, 2004, Richard Levitte - VMS Whacker wrote: steve> steve> > In message <[EMAIL PROTECTED]> on Thu, 18 Nov 2004 09:30:41 +0100 (CET), Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> said: steve> > steve> > richard> OK, that's actually quite easy, I'll have a patch prepared steve> > richard> for review within an hour or so. steve> > steve> > I've got something that seems to work for my purposes. Do you have a steve> > collection of certificates to try this on? The weirder (within a steve> > realistic framework) the better, I'd say. steve> > steve> > I changed ca_check() into a publically available function, and had it steve> > do a bit more thorough checks on the nsCertType values to determine if steve> > the certificate could be a CA certificate or not. steve> > steve> > Oh, and please, if anyone *other* than Steve is interested in this, steve> > please jump in and test! steve> > steve> > I've made the changes against the 0.9.7 branch, and I don;t expect it steve> > to be difficult to apply to 0.9.8-dev. steve> > steve> steve> OK I'll have a look through it. One thing that I'm concerned steve> about is the new error code: X509_V_ERR_INVALID_NON_CA. Is this steve> error code is used when the error code X509_V_ERR_INVALID_CA or steve> others was used previously? As it is right now, you will never see that error. However, when I release the code for proxy certificates (which I currently keep in a separate repository), that error code will be quite important, as that gets us in the new case where certain certificates in the chain (all the proxy certificates and the EE certificate that signs the top proxy certificate) MUST NOT be marked as CA certificates. Actually, the way I've coded the stuff, there should be no behavioral change at all, as I allow both CA and non-CA certificates for the leaf, which seems to be consistent with the previous behavior. However, since I have turned on extension checks in all cases, not just when there's an associated purpose, some errors may become visible more often. Before my change, there was no CA check unless there was an associated purpose, at all. steve> Some applications check the existing error code steve> X509_V_ERR_INVALID_CA and (after performing further checks) steve> override it through the verify callback. If instead it sees a steve> different error it will no longer work. I don't think they'll see any difference. steve> Doing that in 0.9.7 would introduce a binary and source incompatibility. In what way is it a binary incompatibility? I understand this may be about a difference between your and my definition of binary incompatibility. Then again, unless the application processes proxy certificates, it will never see X509_V_ERR_INVALID_NON_CA. I think the change is quite safe. And considering we've done much tougher changes in 0.9.7 lately, this one feels like a drop in the ocean... Cheers, Richard ----- Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
