httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann ...@bee-ware.net>
Subject Re: SSL client certificate extensions requirements backport
Date Wed, 19 Dec 2007 09:10:54 GMT
Dr Stephen Henson wrote:
> Yann wrote:
>> Hi,
>>
>> The joined patch allows the use of client certificate extensions values
>> (by long/short name or OID) in
>> the mod_ssl/SSLRequire directive.
>>
>> This functionnality is available in the 2.2.x and trunk branches but
>> hasn't been backported
>> in the 2.0.61, while this can be a very usefull feature (at least we
>> need it for our product).
>>
>> The backport is taken from trunk since it allows the use of long/short
>> extensions names and it takes into account the token-name change done
>> between 2.2.x and trunk (OID became PeerExtList): the patch allows both
>> names to be used so that configuration files won't need changes.
>>
>> Any hope this could be part of the 2.0.x branch so I won't need to patch
>> the official release ?
>>
> 
> Some comments from an OpenSSL perspective... well also as the author of
> the OpenSSL X509v3 extension parsing code ;-)
> 
> Iterating through extensions can be done more cleanly (i.e. avoiding
> access to internal structures) using X509_get_ext_by_OBJ().
> 
> Similarly you should obtain the value field of an X509_EXTENSION
> structure using X509_EXTENSION_get_data().
> 
> The use of X509V3_EXT_print() for this purpose is problematical.
> 
> It is intended to produce a human readable version of an extension. The
> output format is not cast in stone and as such may change from one
> version of OpenSSL to another to produce a more readable output. That
> can cause problems when an attempt is made to parse its output or even a
> security concern.
> 
> Steve.

Thanks Steve for your comments, I'll modify the patch according to your recommandations, and
propose it for all the
apache branches since I did not change the "trunk" use of OpenSSL.

The changes regarding X509V3_EXT_print() seems more problematic since the extensions values
are used in string
comparison (strcmp and likes), hence the "human readable version", and the code is actually
shared with the other
expressions of the SSLRequire directive.

Do you mean SSLRequire treatment should specialy handle binary comparison for certificate
extensions ?
And a way to write it in the configuration file ...


Mime
View raw message