httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dr Stephen Henson <shen...@oss-institute.org>
Subject Re: SSLRequire & UTF-8 characters & backward compatibility
Date Sun, 02 Jan 2011 12:58:44 GMT
On 31/12/2010 07:52, Kaspar Brand wrote:
> On 30.12.2010 13:43, Stefan Fritsch wrote:
>>>> The latter. I suggest using ASN1_STRING_print_ex() with
>>>> ASN1_STRFLGS_RFC2253 & ~ASN1_STRFLGS_ESC_MSB (will escape them as
>>>> \0).
>>>
>>> OK, makes sense.
>>
>> ASN1_STRING_print_ex escapes a whole lot of other stuff, too. So this 
>> change would also introduce an incompatibility with 2.2.x for all the 
>> SSL_{CLIENT,SERVER}_{I,S}_DN_* variables.
> 
> Good point, I didn't consider this when I came up with the suggestion
> quoted above. My new proposal would be to (only) use
> 
>   ASN1_STRFLGS_ESC_CTRL | ASN1_STRFLGS_UTF8_CONVERT
> 
> for the SSL_{CLIENT,SERVER}_{I,S}_DN_* variables instead. This will
> escape the control characters (0x0 through 0x1f), but not the others
> listed in RFC 2253 - most of which primarily make sense when a complete
> DN is rendered, not single attribute values.
> 
>> This would then also be covered by the SSLOption LegacyDNStringFormat.
> 
> With the proposed change to the ASN1_STRING_print_ex flags, I think that
> we could unconditionally use the new format for the
> SSL_{CLIENT,SERVER}_{I,S}_DN_* variables, as there is no incompatibility
> with "simple" strings (i.e., 7-bit characters encoded as
> PRINTABLESTRINGs or IA5STRINGs). For non-ASCII characters, the current
> code produces unusable results in many cases anyway, so I would not try
> to retain that as a "legacy" string rendering.
> 
>> I would like to have opinions from other people before committing this.
> 
> Yes, please - additional opinions appreciated.
> 

Well it wont be totally compatible with the old format even if it only contains
7-bit ASCII characters. For example the tab character would be escaped.

There is a bug in OpenSSL currently for those options: it doesn't escape the
escape character itself (which it should treat as a special case and always
escape it if any other escaping is in use). That means some representations are
ambiguous with those options.

When that is fixed even 7 bit without control characters will have at least one
difference: the backslash will always appear escaped as "\\".

Steve.
-- 
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org

Mime
View raw message