Nice.
I don't think it makes much sense with per-certificate callbacks. I think it should be enough to report the kind of problem to the application (certificate chain broken, root cert not trusted, signatures that aren't valid, some certificate in the chain has expired). And then give the application the option of accepting the peer anyway.
As for flags, Peter Gutmanns style guide should give some guidance. I don't remember much of the details. Guess one should start with the flags of the "critical" kind, and refuse to accept certificates with unknown or unimplemented critical flags.
One important part (although perhaps not very exciting) is testcases that exersize all the failure modes listed above.
/ Niels Möller (vässar rödpennan)
Previous text:
2004-02-02 22:15: Subject: Re: SSL part two
I've added some peer certificate verification code. It makes sure the chain is unbroken, that the signatures are correct, and that the root of the certificate chain provided is trusted.
I haven't yet added code to check the dates on the certificates, but should get to that soon. I also haven't done anything with the flags (anyone up for that???).
I was thinking about adding an optional callback that would be called in the event of a problem with one of the certificates (wrong flags, untrusted, etc) so that an application could make a decision about whether to override the verification failure. Any thoughts?
Bill
/ Brevbäraren