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. Kaspar