Hello Steve,

Stephen Henson via RT wrote:
> [[EMAIL PROTECTED] - Mon Feb 10 20:02:40 2003]:

>>OK.
>>I should clarify myself:
>>It is to do it correctly, but not needed to fix the actual problem.
>>
>>>However option 4 easy to do and could be argued as being a "bug fix".
>>
>>OK.
>>
>>Perhaps something like:
>>    build the chain only with the certs supplied with
>>    SSL_CTX_add_extra_chain_cert()

> Perhaps I should clarify myself too :-)
> 
> The current situation is not good. If the primitive auto chain building
> comes up with the wrong answer then there isn't any easy method I can 
> think of that will allow it to fix things.

ACK

> Giving no certificate store at all and doing all its own verification
> might work but it's a hack.
> 
> As a result IMHO we need a way to do *something* in OpenSSL 0.9.7X.
> 
> If it is decided that a 0.9.7X fix is needed then this should be a
> minimal bug fix solution that keeps the changes in functionality down to
> a minimum but gives the application some method of correcting things
> when the chain build breaks. 

ACK

> For that maybe a new flag or possibly auto disable of the chain build if
> any extra certs are added. After all if the application is supplying
> extra certs it presumably is expecting the auto chain build to fail
> anyway? I can't see any legitimate reason for supplying extra certs
> *and* having auto chain build.

That confused me too.

> The extra certs would be sent verbatim which is what 0.9.7 currently
> does anyway.

> Doing things properly will need new functionality and new functions and
> possibly break existing applications. As such that should be a 0.9.8 target.

ACK

> For example what purpose and trust settings do you use in the chain
> building? The defaults will be SSL server for servers and SSL client for
> clients but some applications might need something different which the
> current primitive chain build will handle but the "correct" version wont.

I don't think that we should do there to much checks.
We should check:

* the validity period (begin & end) of all certs
* the trust settings for all certificates
* the purpose for the CA certs

I don't think we really should check the purpose
of the own certificate.
(At least not break if it doesn't matches.)
A mismatching purpose should result in a warning but
not in an error.

But since OpenSSL has no warnings...

If the purpose of the certificate doesn't match,
the peer should decide if a connection is established.

In special cases it is usefull to use a client cert
for a server and a server key for a client.

Bye

Goetz

-- 
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0,  Fax: +49-(0)40 80 80 26 -126
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to