[EMAIL PROTECTED] wrote:
>
> Rich is right. A recursive trial-and-error is the way to go. It should be
> combined with extension checking.
>
> It�s sad that Openssl discards keyusage restrictions and other extensions, as
> they are definitely not there for being discarded.
>
[description of extension handling omitted]
It doesn't discard them more it ignores them. Historically (based on
SSLeay) it had almost no extension handling at all (only Netscape
specific extensions) its only relatively recently that you could even
produce things like basicConstraints in certificates.
I do know how to handle extensions and certificate verify. However
getting this going is an enormous job because there are lots of
historical parts that are incompatible with the whole thing: X509_LOOKUP
and the standard verify code for example. The very first thing you need
for this is a CRL/certificate database API able to return more than one
matching certificate for various criteria and handling things like trust
settings etc. AFAIK there is no "standard" for this kind of thing and
various APIs I've seen handle this in totally incompatible and partially
broken ways.
Yes its on my list of "things to do" but so are lots of other things...
However the callbacks that handle verifying are replacable so an
application can provide its own verify mechanisms if it doesn't like the
standard ones.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
