On Thu, Nov 18, 2004, Richard Levitte - VMS Whacker wrote: > 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... >
That was based on my initial quick scan of the code and the possible use of a new error condition which might occur when an existing one does and the breakage of anything that overrode specific errors in the callback. I'll check it through more thoroughly. If you never get that new error code then I agree there wont be any incompatibility on that basis. That leaves two cases based on my current understanding of the patch [subject to change when I've scanned it further :-)] . One is applications that expect the lack of CA checking when they set no purpose, another is customized purpose checking where someone defines their own purpose with its own overrides. I don't *think* many applications do either but they would be broken by the change as I understand it. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
