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.
