httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kaspar Brand <>
Subject Re: SSLRequire & UTF-8 characters & backward compatibility
Date Fri, 31 Dec 2010 07:52:35 GMT
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


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.


View raw message