Ren� G. Eberhard wrote:
>
>
> > OPEN ISSUES
> >
> > o internal_verify doesn't know about X509.v3 (basicConstraints
> > CA flag ...)
>
> I'm still interested in the design, API and realisation of the X.509
> verification
> stuff. I hope that we can have a view into the specification, design and API
> spec.
>
At this point things are still at the "concept stage" i.e. I'm thinking
about it. I welcome any ideas or thoughts on the matter.
Currently the problem is that the verification is largely hard coded and
ignores such things as revocation checks and extensions and has a
primitive way of obtaining issuer certificates.
My initial thoughts are to have something backwards compatible but in
which all the currently hard coded functions can be replaced. So what
you have is a set of callbacks which do something like this:
1. Retrieve the issuers certificate.
2. Check the internal consistency of a certificate (e.g. validity
dates).
3. Check the extensions of a certificate: e.g. is it a CA and is the
pathlen constraint OK.
4. Check the signature of a certificate.
5. Check the revocation status of a certificate.
6. Determine the trust status of a certificate.
These is some overlap between these functions though. For example a
store might have several certificates with various expiry dates some of
which are currently invalid so option 1 will do some validity checking
of its own.
The input to the verify process will be a superset of the current
system. Currently you can input a leaf certificate and a set of
untrusted certificates. The lack of extension verification means that
most applications leave the untrusted set empty because its a security
hole without proper CA checking.
In addition some extra parameters can be passed to the verify operation.
This might include:
1. A certificate purpose, e.g. SSL server, client, S/MIME etc.
2. A "strict" option which will determine how fussy the checks are (if
you follow the letter of PKIX you'll reject some commonly used CAs
chains).
3. Additional checks, this might include the SSL server name or the
S/MIME recipients address.
4. The time to check validity against: currently you can only check
against the current time.
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]
