On 24/11/2010 07:07, Kaspar Brand wrote:
> On 20.11.2010 20:24, Stefan Fritsch wrote:
>> On Fri, 19 Nov 2010, Joe Orton wrote:
>>> We could support this better by having a new set of exports:
>>>
>>> SSL_{CLIENT,SERVER}_{I,S}_UTF8DN_*(_n)?
>>>
>>> (or something similarly named)
>>>
>>> which works the same as _DN_ but exports the attributes as a UTF-8 byte
>>> seequence regardless of the underlying ASN.1 type; this would be a
>>> relatively simple hack.
>>
>> Or have a (per vhost) directive that enables conversion for all
>> SSL_*_S_DN_* and SSL_*_S_DN to UTF8. IMHO, this could even be enabled by
>> default in 2.4.
>
> I prefer the latter approach, yes (there's already an awful lot of SSL_*
> something variables).
>
> Given the fact that mod_ssl's current behavior with non-ASCII characters
> (i.e., outside the 0-127 range) is mostly undefined and/or sometimes
> even erroneous (a BMPString in the subject or issuer DN will end up as
> an empty SSL_*_*_DN_* variable, due to the initial null byte), I would
> suggest the following solution:
>
> - for all SSL_{CLIENT,SERVER}_{I,S}_DN_* variables, use UTF-8 by default
> (i.e., adapt ssl_engine_vars.c:ssl_var_lookup_ssl_cert_dn() to convert
> TeletexString, UniversalString and BMPString types to UTF8String)
>
> - for SSL_{CLIENT,SERVER}_{I,S}_DN, don't use X509_NAME_oneline()
> any more and switch to X509_NAME_print_ex() instead. What flags
> should be used is probably debatable - I would recommend to go with
> XN_FLAG_RFC2253 (note that using XN_FLAG_ONELINE with
> X509_NAME_print_ex doesn't produce the same string as
> X509_NAME_oneline, so this will break backward compatibility
> in any case)
>
> - add another parameter to the SSLOptions directive which allows
> re-enabling the "old" string rendering for
> SSL_{CLIENT,SERVER}_{I,S}_DN (so the new default would be to rely
> on X509_NAME_print_ex - even for 2.2 -, but people could restore the
> current behavior through this option)
>
It's a very good idea to avoid X509_NAME_oneline() wherever possible as it is
highly broken, can produce ambiguous output (of the Bobby Tables variety) and at
other times be just plain wrong (BMPStrings is one of many examples).
We have to retain it in OpenSSL for backwards compatibility though. I'd throw it
out tomorrow if I could get away with it.
You can get a UTF8String from most string types using ASN1_STRING_to_UTF8().
This should be adequate for most purposes: it doesn't handle the more bizarre
TeletexString shift conversions but those are rarely encountered in practice.
Steve.
--
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org
