On Sunday 02 January 2011, Dr Stephen Henson wrote: > 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.
I don't think we need to care about control characters. I can't imagine any legitimate use in certificates. > 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 "\\". I guess backslashes are very seldomly used in certificates. Therefore, I would just document that change for now and only add a backward compatibility option if the change turns out to be a problem for users.